应该阻止查询的 postgres 中的锁定和事务

Question

让我们假设在 SQL 窗口 1 中我这样做：

-- query 1 
BEGIN TRANSACTION;
UPDATE post SET title = 'edited' WHERE id = 1;
-- note that there is no explicit commit

然后从另一个窗口（窗口 2）我做：

-- query 2
SELECT * FROM post WHERE id = 1;

我得到：

1 | original title

这很好，因为默认隔离级别是 READ COMMITTED 并且因为查询 1 从未提交，所以它执行的更改在我从窗口 1 显式提交之前是不可读的。

事实上，如果我在窗口 1 中执行以下操作：

COMMIT TRANSACTION;

如果我重新运行查询 2，我可以看到更改。

1 | edited

我的问题是：

为什么第一次运行查询 2 时返回正常？ 我期望它会阻塞，因为窗口 1 中的事务尚未提交，并且放置在id = 1行上的锁是（应该是）一个未释放的独占锁，应该像在窗口 2 中执行的那样阻塞读取。所有的休息对我来说很有意义，但我希望SELECT卡住，直到在窗口 1 中执行显式提交。

Answer 1

您描述的行为在任何事务关系数据库中都是正常的和预期的。

如果 PostgreSQL 向您显示为第一个SELECT edited的值，那么这样做是错误的 - 这称为“脏读”，并且在数据库中是个坏消息。

PostgreSQL 将被允许在SELECT等待直到您提交或回滚，但 SQL 标准不要求这样做，您没有告诉它您要等待，并且它不必等待任何技术原因，因此它立即返回您要求的数据。 毕竟，在它被提交之前，该update只是一种存在——它仍然可能发生也可能不会发生。

如果 PostgreSQL 总是在这里等待，那么您很快就会遇到这样一种情况，即一次只有一个连接可以对数据库执行任何操作。 性能不佳，而且在绝大多数情况下完全没有必要。

如果您想等待并发UPDATE （或DELETE ），您可以使用SELECT ... FOR SHARE 。 （但请注意，这不适用于INSERT ）。

---

细节：

没有FOR UPDATE或FOR SHARE子句的SELECT不使用任何行级锁。 因此，它可以查看当前已提交的行，并且不受任何可能正在修改该行的正在进行的事务的影响。 文档的MVCC 部分解释了这些概念。 一般的想法是 PostgreSQL 是写时复制，版本控制允许它根据事务或语句在它开始时可以“看到”的内容返回正确的副本 - PostgreSQL 称之为“快照”。

在默认的READ COMMITTED隔离创建快照在语句级别，因此，如果您SELECT一排， COMMIT从另一个事务它的变化， SELECT它再次，你会甚至在一个TRANSATION看到不同的值。 如果不想看到事务开始后提交的更改，可以使用SNAPSHOT隔离，或者使用SERIALIZABLE隔离来进一步保护某些类型的事务相互依赖。

请参阅文档中的事务隔离章节。

如果您希望SELECT等待正在进行的事务提交或回滚对所选行的更改，则必须使用SELECT ... FOR SHARE 。 这将阻塞由UPDATE或DELETE获取的锁，直到获取锁的事务回滚或提交。

INSERT是不同的——元组在提交之前不存在于其他事务中。 等待并发INSERT的唯一方法是获取EXCLUSIVE表级锁，因此您知道在您读取表时没有其他人在更改该表。 通常需要这样做意味着您在应用程序中存在设计问题 - 您的应用程序不应该关心是否有未提交的insert仍在进行中。

请参阅文档的显式锁定章节。

Answer 2

在PostgreSQL 的 MVCC实现中，原则是读不阻塞写，反之亦然。 手册：

使用 MVCC 并发控制模型而不是锁定的主要优点是在 MVCC 中为查询（读取）数据获取的锁与为写入数据获取的锁不冲突，因此读取从不阻塞写入，写入从不阻塞读取。 即使在通过使用创新的可序列化快照隔离(SSI) 级别提供最严格的事务隔离级别时，PostgreSQL 也能保持这种保证。

每个事务只看到（大部分）事务开始前已经提交的内容。

这并不意味着有好多没有锁定。 一点也不。 对于许多操作，需要获取各种锁。 并应用各种策略来解决可能的冲突。