当 UPDATE WHERE 子句进行表扫描时，Postgres 锁行为是什么？

Question

假设您有一个包含数千万行的大表。

您想要UPDATE large_table SET col=value WHERE col=other_value...但未col建立索引，并且EXPLAIN显示该查询将对整个表执行 seq 扫描。

这里的锁行为是什么？根据大多数说法，Postgres 仅锁定 UPDATE 查询受影响的行，并且没有锁升级。那么它是否首先搜索要更新的行，然后只锁定找到的行？不过，在这种情况下，其他查询同时更新行似乎可能会出现问题。它是否“在找到每一行时”锁定它们，即在进行 seq 扫描时逐步锁定行？

因此，我认为这里最好的情况是它在找到行时锁定行，并且（仅）受影响的行将被锁定，直到 UPDATE 查询完成为止。

但我担心此查询可能最终会阻止对表的所有写入，直到完成为止。

我读过这篇文章： https: //habr.com/en/company/postgrespro/blog/503008/我认为最坏的情况不会发生，但在这里https://blog.heroku.com/curious-case-table -locking-update-query是类似信息的可能不准确表示，这让我有些怀疑。

该应用程序仅使用SELECT,SELECT FOR UPDATE和UPDATE查询（即除这些之外没有其他显式锁）。该表有其他表的外键，其他表也有该表的外键。

我们使用的是 Postgres 11。

Answer 1

为了进行讨论，我们假设您的执行计划如下所示

        QUERY PLAN        
--------------------------
 Update on mytab
   ->  Seq Scan on mytab
         Filter: (id = 1)

我还假设您正在使用默认的READ COMMITTED隔离级别。

然后PostgreSQL将顺序读取该表。

每当它找到与过滤器匹配的行时，该行将被锁定并更新。

如果锁定行被并发查询阻塞，PostgreSQL 会等待直到锁消失。然后，它重新评估过滤条件并继续（如果条件因并发修改而不再适用）或锁定并更新修改的行。

请参阅文档：

UPDATE、DELETE、SELECT FOR UPDATE和命令的行为与搜索目标SELECT FOR SHARE行相同：它们只会查找截至命令开始时间已提交的目标行。SELECT然而，这样的目标行在被发现时可能已经被另一个并发事务更新（或删除或锁定）。在这种情况下，潜在的更新程序将等待第一个更新事务提交或回滚（如果仍在进行中）。如果第一个更新程序回滚，则其效果将被否定，第二个更新程序可以继续更新最初找到的行。如果第一个更新程序提交，则第二个更新程序将忽略第一个更新程序删除的行，否则它将尝试将其操作应用于该行的更新版本。WHERE重新评估命令（子句）的搜索条件，以查看该行的更新版本是否仍然与搜索条件匹配。如果是，则第二更新器使用该行的更新版本继续其操作。

特别是，两个分别修改多行的语句可能会UPDATE彼此死锁，因为它们在执行过程中获取锁，并且锁始终保持到事务结束为止。