Postgres中的Atomic UPDATE .. SELECT

Question

我正在建立各种排队机制.有需要处理的数据行和状态标志.我正在使用一个update .. returning条款来管理它:

UPDATE stuff
SET computed = 'working'
WHERE id = (SELECT id from STUFF WHERE computed IS NULL LIMIT 1)
RETURNING * 

嵌套的选择部分是否与更新锁相同,或者我是否有竞争条件？如果是这样,内部选择需要是select for update吗？

Answer 1

虽然Erwin的建议可能是获得正确行为的最简单方法(只要你用SQLSTATE40001 获得异常就重试你的事务),按照他们的性质对应用程序进行排队往往会更好地处理阻止有机会轮到他们的请求队列比PostgreSQL实现的SERIALIZABLE事务,它允许更高的并发性,并且对碰撞的可能性更加"乐观".

问题中的示例查询(如图所示)在默认READ COMMITTED事务隔离级别中将允许两个(或更多)并发连接"声明"队列中的同一行.会发生什么是这样的:

• T1启动并获得锁定UPDATE阶段中的行.
• T2在执行时间内重叠T1并尝试更新该行.它阻止等待T1 COMMIT或ROLLBACKT1.
• T1提交,已成功"声称"该行.
• T2尝试更新行,发现T1已经拥有,查找该行的新版本,发现它仍然满足选择条件(只是id匹配),并且还"声明"该行.

它可以被修改为正常工作(如果您使用的是允许FOR UPDATE子查询中的子句的PostgreSQL版本).只需添加FOR UPDATE到选择id的子查询的末尾,这将发生:

• T1启动,现在在选择 id 之前锁定行.
• T2在执行时间内重叠T1,并在尝试选择id时挂起,等待T1 COMMIT或ROLLBACKT1.
• T1提交,已成功"声称"该行.
• 当T2能够读取行以查看id时,它会看到它已被声明,因此它找到下一个可用的id.

在REPEATABLE READ或SERIALIZABLE事务隔离级别,写入冲突会引发错误,您可以捕获并确定基于SQLSTATE的序列化失败,然后重试.

如果您通常需要SERIALIZABLE事务但是想要避免在排队区域中重试,则可以通过使用建议锁来实现此目的.

Answer 2

如果您是唯一的用户,则查询应该没问题.特别是,查询本身(外部查询和子查询之间)没有竞争条件或死锁.我在这里引用手册:

但是,事务永远不会与自身冲突.

对于同时使用,问题可能更复杂.您可以使用SERIALIZABLE交易模式保证安全:

BEGIN ISOLATION LEVEL SERIALIZABLE;
UPDATE stuff
SET    computed = 'working'
WHERE  id = (SELECT id FROM stuff WHERE computed IS NULL LIMIT 1)
RETURNING * 
COMMIT;

在这种情况下,您需要准备序列化失败并重试查询.

但我不完全确定这不是矫枉过正.我会要求@kgrittn停下来..他是并发和可序列化事务的专家.

他做到了.:)

两全其美

在默认事务模式下运行查询READ COMMITTED.

对于Postgres 9.5或更高版本使用FOR UPDATE SKIP LOCKED.看到:

• Postgres UPDATE ... LIMIT 1

对于旧版本computed IS NULL,在外部显式重新检查条件UPDATE:

UPDATE stuff
SET    computed = 'working'
WHERE  id = (SELECT id FROM stuff WHERE computed IS NULL LIMIT 1)
AND   computed IS NULL;

正如@ kgrittn在他的回答评论中所建议的那样,这个查询可能在没有做任何事情的情况下变得空洞,在(不太可能的)情况下它与并发事务交织在一起.

因此,它将像交易模式中的第一个变体一样工作SERIALIZABLE,您必须重试 - 只是没有性能损失.

唯一的问题是:虽然冲突是不太可能的,因为机会之窗非常小,但它可能在重负荷下发生.你无法确定是否最后没有剩下的行.

如果这无关紧要(就像你的情况一样),你就完成了.
如果是的话,是绝对的把握,开始多了一个查询明确锁定你会得到一个空的结果后.如果这个空了,你就完成了.如果没有,继续.
在plpgsql中它可能如下所示:

LOOP
   UPDATE stuff
   SET    computed = 'working'
   WHERE  id = (SELECT id FROM stuff WHERE computed IS NULL
                LIMIT 1 FOR UPDATE SKIP LOCKED);  -- pg 9.5+
   -- WHERE  id = (SELECT id FROM stuff WHERE computed IS NULL LIMIT 1)
   -- AND    computed IS NULL; -- pg 9.4-

   CONTINUE WHEN FOUND;  -- continue outside loop, may be a nested loop

   UPDATE stuff
   SET    computed = 'working'
   WHERE  id = (SELECT id FROM stuff WHERE computed IS NULL
                LIMIT 1 FOR UPDATE);

   EXIT WHEN NOT FOUND;  -- exit function (end)
END LOOP;

这应该会给你两全其美:性能和可靠性.