SELECT ... FOR UPDATE SKIP LOCKED 在 REPEATABLE READ 事务中

Question

我的 PostgreSQL 10.5 数据库中有以下语句，我在 repeatable read 事务中执行：

delete from task
  where task.task_id = (
    select task.task_id
    from task
    order by task.created_at asc
    limit 1
    for update skip locked
  )
  returning
    task.task_id,
    task.created_at

不幸的是，当我运行它时，我有时会得到：

[67] ERROR:  could not serialize access due to concurrent update
[67] STATEMENT:  delete from task
  where task.task_id = (
    select task.task_id
    from task
    order by task.created_at asc
    limit $1
    for update skip locked
  )
  returning
    task.task_id,
    task.created_at

这意味着事务回滚，因为其他一些事务同时修改了记录。 （我认为？）

我不太明白这个。不同的事务如何修改使用for update skip locked 选择并删除的记录？

Answer 1

This quote from the manual 讨论您的情况完全正确：

UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE 命令 在搜索目标行方面的行为与 SELECT 相同：它们 只会找到在事务中提交的目标行 开始时间。但是，这样的目标行可能已经更新 （或删除或锁定）由另一个并发事务的时间 找到了。在这种情况下，可重复读事务将等待 第一个更新事务提交或回滚（如果是 仍在进行中）。如果第一个更新程序回滚，那么它的影响 被否定并且可重复读取事务可以继续 更新最初找到的行。但是如果第一个更新者提交 （实际上更新或删除了该行，而不仅仅是锁定它）然后 可重复读取事务将随消息一起回滚

ERROR:  could not serialize access due to concurrent update

意思是，您的事务无法锁定开始的行 - 由于并发写访问首先到达那里。 SKIP LOCKED 无法让您完全摆脱这种情况，因为可能不再有可以跳过的锁，如果自事务开始以来该行已经被更改（并且更改已提交 - 因此锁被释放），我们仍然会遇到序列化失败。

对于默认的READ COMMITTED 事务隔离，相同的语句应该可以正常工作。相关：

• Postgres UPDATE … LIMIT 1