为什么 PostgreSQL 需要 ACCESS EXCLUSIVE LOCK？

Question

我知道 PostgreSQL 为并发控制提供了多种锁定模式。当我通读他们的文件时，我不明白为什么ACCESS EXCLUSIVE在任何情况下都需要锁。EXCLUSIVE锁和ACCESS EXCLUSIVE锁之间的唯一区别似乎是ACCESS EXCLUSIVE锁不允许从表中读取。

但是，人们能够阅读不是一件好事吗？在什么情况下应该阻止用户阅读？在文档中，我看到通常DROP TABLE等会使用ACCESS EXCLUSIVE锁，但为什么呢？我在想，也许当您删除表时，当您尝试读取时，数据已经部分消失，因此结果将被破坏。但是后来我意识到由于 Postgres 中的所有内容都是事务性的，DROP TABLE因此在提交之前不应该生效。所以我的猜测应该是错误的。

我还是很困惑。ACCESS EXCLUSIVE当您将它与EXCLUSIVE锁定进行比较时，为什么又需要锁定？我最好的猜测是用ACCESS EXCLUSIVE锁替换锁EXCLUSIVE不会破坏 PostgreSQL。只是有时人们不希望别人阅读。我错过了什么？

Answer 1

如果您查看文档，您会看到获取此类锁的操作列表：

由所获取的DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL，和REFRESH MATERIALIZED VIEW（不含CONCURRENTLY）的命令。许多形式的ALTER TABLE也获取此级别的锁。

所有这些都是物理（重新）移动行，因此在这些期间读取至少是非常不可预测的。

谈到事务，当您开始从表中读取并且另一个进程稍后决定删除它时，后者必须等到读取完成 - 较早的人仍将获得请求的数据，并且当该事务提交时，第二个进程接受锁定并放下桌子。反过来，在等待删除事务提交后，读取将失败，因为不再有任何可读取的内容。

如果 PostgreSQL 允许从被删除的表中读取，那将意味着两件事。一个是，如果我没记错的话，存在一个READ UNCOMMITTED隔离级别。虽然您可以选择它，但实际上READ COMMITTED，这意味着没有交易能够看到其他交易的中间状态。另一种情况是，正如您已经猜到的那样，可能只返回了所需数据的一部分。这将导致不可预测的行为，这是您希望从数据库系统中获得的最后一件事。

此外，CLUSTER并且VACUUM FULL正在两个文件之间移动数据 - 如何决定在哪个文件中追逐行？

总而言之，在某些情况下读取数据并不是那么紧迫。或者在这种情况下DROP TABLE，TRUNCATE它不再那么紧迫了。