Postgres 中的脏读

发布于 2024-07-27 12:04:06 字数 488 浏览 11 评论 0原文

我有一个长时间运行的函数,应该插入新行。 如何查看该功能的进度?

我认为脏读会起作用,所以我读了 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

用心笑 2024-08-03 12:04:06

PostgreSQL 没有实现让您从函数外部查看此信息的方法,即 READ UNCOMMITTED 隔离级别。 您的基本两个选项是:

  • 让函数使用 时不时地发出通知,向您展示您已经走了多远。
  • 使用 dblink 之类的东西从函数返回到同一个数据库,并从那里更新计数器表。 由于这是一个完全独立的事务,因此一旦该事务提交,计数器就会可见 - 您不必等待主事务(在函数调用周围)完成。

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:

  • Have the function use RAISE NOTICE every now and then to show you how far along you are
  • Use something like dblink from the function back to the same database, and update a counter table from there. Since that's a completely separate transaction, the counter will be visible as soon as that transaction commits - you don't have to wait for the main transaction (around the function call) to finish.
‖放下 2024-08-03 12:04:06

对于 9.0 及以下版本: PostgreSQL 事务隔离

在 PostgreSQL 中,您可以请求四种标准事务隔离级别中的任何一种。 但在内部,只有两个不同的隔离级别,分别对应于“已提交读”和“可串行化”级别。 当您选择“未提交读”级别时,您实际上会获得已提交读,而当您选择“可重复读”时,您实际上会获得可串行化,因此实际隔离级别可能比您选择的更严格。 这是 SQL 标准允许的:四种隔离级别仅定义哪些现象不能发生,而不定义哪些现象必须发生。

对于从 9.1 到 current(15) 的版本:PostgreSQL 事务隔离

在 PostgreSQL 中,您可以请求四种标准事务隔离级别中的任何一种,但在内部仅实现了三种不同的隔离级别,即 PostgreSQL 的未提交读模式的行为类似于已提交读。 这是因为它将标准隔离级别映射到 PostgreSQL 的多版本并发控制架构的唯一明智的方法。

For versions up to 9.0: PostgreSQL Transaction Isolation

In PostgreSQL, you can request any of the four standard transaction isolation levels. But internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you really get Read Committed, and when you select Repeatable Read you really get Serializable, so the actual isolation level might be stricter than what you select. This is permitted by the SQL standard: the four isolation levels only define which phenomena must not happen, they do not define which phenomena must happen.

For versions from 9.1 to current(15): PostgreSQL Transaction Isolation

In PostgreSQL, you can request any of the four standard transaction isolation levels, but internally only three distinct isolation levels are implemented, i.e., PostgreSQL's Read Uncommitted mode behaves like Read Committed. This is because it is the only sensible way to map the standard isolation levels to PostgreSQL's multiversion concurrency control architecture.

季末如歌 2024-08-03 12:04:06

即使隔离级别为 READ UNCOMMITTED,PostgreSQL 中也不会发生脏读。 并且,文档如下所述:

PostgreSQL 的未提交读模式的行为类似于已提交读。

因此,READ UNCOMMITTEDPostgreSQL 中的 READ COMMITTED 具有与其他数据库不同的相同特征,简而言之,READ UNCOMMITTED > 和 READ COMMITTEDPostgreSQL 中是相同的。

并且,根据我的实验,下表显示了 PostgreSQL 中的哪个隔离级别会出现哪种异常:

异常读取 未提交读取 已提交可重复读取 可序列化
脏读NoNoNoNo
不可重复读是 否
幻读是 是
丢失更新
写入倾斜
(序列化异常)

使用SELECT FOR UPDATE

异常读取 未提交的已提交的重复读取 可序列化
脏读读取
不可重复读取
幻读NoNoNoNo
丢失更新NoNoNoNo
写入倾斜
(序列化异常)
NoNoNoNo

Dirty read doesn't occur in PostgreSQL even the isolation level is READ UNCOMMITTED. And, the documentation says below:

PostgreSQL's Read Uncommitted mode behaves like Read Committed.

So, READ UNCOMMITTED has the same characteristics of READ COMMITTED in PostgreSQL different from other databases so in short, READ UNCOMMITTED and READ COMMITTED are the same in PostgreSQL.

And, this table below shows which anomaly occurs in which isolation level in PostgreSQL according to my experiments:

AnomalyRead UncommittedRead CommittedRepeatable ReadSerializable
Dirty ReadNoNoNoNo
Non-repeatable ReadYesYesNoNo
Phantom ReadYesYesNoNo
Lost UpdateYesYesNoNo
Write Skew
(Serialization Anomaly)
YesYesYesNo

With SELECT FOR UPDATE:

AnomalyRead UncommittedRead CommittedRepeatable ReadSerializable
Dirty ReadNoNoNoNo
Non-repeatable ReadNoNoNoNo
Phantom ReadNoNoNoNo
Lost UpdateNoNoNoNo
Write Skew
(Serialization Anomaly)
NoNoNoNo
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文