PostgreSQL 选择...更新 : What happens with concurrent long running queries?

Question

我想知道当两个事务并行执行 SELECT ... FOR UPDATE 查询时会发生什么。背景是我想使用 SELECT ... FOR UPDATE 和 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 使用与 T1 相同的 WHERE 子句和参数执行 SELECT ... FOR UPDATE，这也需要一些时间。
5. T1 最终找到所有行，锁定它们
6. T1 开始更新行(例如，将它们标记为现在正在处理中)
7. T2 终于找到行 => 现在会发生什么？

一些问题:

1. 我假设 T1 在原子操作中锁定行。这是正确的吗？
2. 所以当 T2 最终找到它的结果集并尝试锁定它无法做到的行时？ T2 在这种情况下如何 react ？我的假设是它会一直等到 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 将获取每一行的最新版本。