Postgres 中的脏读
我有一个长时间运行的函数,应该插入新行。 如何查看该功能的进度?
我认为脏读会起作用,所以我读了 http:// www.postgresql.org/docs/8.4/interactive/sql-set-transaction.html 并提出以下代码并在新会话中运行它:
SET SESSION CHARACTERISTICS AS SERIALIZABLE;
SELECT * FROM MyTable;
Postgres 给了我一个语法错误。 我究竟做错了什么? 如果我做得正确,当那个长函数仍在运行时我会看到插入的记录吗?
谢谢。
I have a long running function that should be inserting new rows. How do I check the progress of this function?
I was thinking dirty reads would work so I read http://www.postgresql.org/docs/8.4/interactive/sql-set-transaction.html and came up with the following code and ran it in a new session:
SET SESSION CHARACTERISTICS AS SERIALIZABLE;
SELECT * FROM MyTable;
Postgres gives me a syntax error. What am I doing wrong? If I do it right, will I see the inserted records while that long function is still running?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
PostgreSQL 没有实现让您从函数外部查看此信息的方法,即 READ UNCOMMITTED 隔离级别。 您的基本两个选项是:
时不时地发出通知
,向您展示您已经走了多远。PostgreSQL does not implement a way for you to see this from outside the function, aka
READ UNCOMMITTED
isolation level. Your basic two options are:RAISE NOTICE
every now and then to show you how far along you are对于 9.0 及以下版本: PostgreSQL 事务隔离
对于从 9.1 到 current(15) 的版本:PostgreSQL 事务隔离
For versions up to 9.0: PostgreSQL Transaction Isolation
For versions from 9.1 to current(15): PostgreSQL Transaction Isolation
即使隔离级别为 READ UNCOMMITTED,PostgreSQL 中也不会发生脏读。 并且,文档如下所述:
因此,
READ UNCOMMITTED
与 PostgreSQL 中的READ COMMITTED
具有与其他数据库不同的相同特征,简而言之,READ UNCOMMITTED
> 和READ COMMITTED
在 PostgreSQL 中是相同的。并且,根据我的实验,下表显示了 PostgreSQL 中的哪个隔离级别会出现哪种异常:
(序列化异常)
使用
SELECT FOR UPDATE
:(序列化异常)
Dirty read doesn't occur in PostgreSQL even the isolation level is
READ UNCOMMITTED
. And, the documentation says below:So,
READ UNCOMMITTED
has the same characteristics ofREAD COMMITTED
in PostgreSQL different from other databases so in short,READ UNCOMMITTED
andREAD COMMITTED
are the same in PostgreSQL.And, this table below shows which anomaly occurs in which isolation level in PostgreSQL according to my experiments:
(Serialization Anomaly)
With
SELECT FOR UPDATE
:(Serialization Anomaly)