PostgreSQL SELECT ... FOR UPDATE：并发长时间运行查询会发生什么？

Question

SELECT ... FOR UPDATE我想知道当两个事务并行执行查询时会发生什么。背景是我想使用SELECT ... FOR UPDATEwith实现一个作业队列SKIP LOCKED，如下所示： https: //vladmihalcea.com/database-job-queue-skip-locked/。但在本文中，查询非常简单。

具有两个事务 T1 和 T2 的示例（事务隔离级别设置为READ_COMMITTED）：

1. T1开始
2. T1 执行SELECT ... FOR UPDATE，搜索新行，这需要一些时间。
3. T2开始
4. T2 使用SELECT ... FOR UPDATE与 T1 相同的 WHERE 子句和参数执行，这也需要一些时间。
5. T1 最终找到所有行，锁定它们
6. T1 开始更新行（例如，将它们标记为正在 IN_PROGRESS）
7. T2 终于找到行 => 现在会发生什么？

一些问题：

1. 我假设 T1 在原子操作中锁定行。它是否正确？
2. 那么，当 T2 最终找到它的结果集并尝试锁定行时，它无法做到这一点？在这种情况下，T2 有何反应？我的假设是它会等到 T1 释放锁（不使用 NOWAIT 时）。
3. 如果 T2 在 T1 进行任何更改（例如将作业状态从 NEW 更改为 IN_PROGRESS）之前完成查询会怎样？两个事务能否找到相同的结果集？
4. 如果 T1 以某种方式标记锁定的行（例如，通过将状态列从 NEW 更改为 IN_PROGRESS）并且 T2 查找原始状态 (NEW)，那么 T2 会使用SKIP LOCKED跳过标记的行吗？T1 进行更改后，T2 会重新评估其结果集吗？

Answer 1

1. 每个事务在找到行时都会锁定这些行，因此锁定不是原子的。可能会出现 T1 锁定几行而 T2 锁定其他一些行的情况。

2. 由于每个事务在找到行时立即锁定行，因此这种情况不会发生。一行要么被锁定，在这种情况下它被跳过，要么它未被锁定，在这种情况下它被锁定。

3. 如果 T1 在 T2 扫描完表之前提交，T2 会很乐意锁定 T1 已经处理过的所有行。

4. 是的，那会起作用的。T2 将在检查条件并锁定该行之前获取每行的最新版本。