> So use names/advisory locks: create a named lock called "order-1234" where 1234 is tbe ID of the order. If all your locking is single-transaction, then I thi

> So use names/advisory locks: create a named lock called "order-1234" where 1234 is tbe ID of the order. If all your locking is single-transaction, then I think a better technique might actually to have a separate table where you have the individual lock IDs and use SELECT FOR UPDATE on the appropriate row there[1] -- only to obtain the lock. (Of course, most of the caveats you've spelled out in this thread still apply wrt. ordering, etc.) Reasoning: Most named lock/advisory lock implementations don't participate in the current transaction, so you can end with "stuck" locks where the lock was acquired, but never released because the transaction before the "release" action failed. It goes without saying that this is not a problem that can be solved client-side, so you end up having to have "lock cleanup" (and how can you be sure that cleaning up a lock is actually the right thing, etc.). [1] You might also have to UPSERT rows depending on how "dynamic" your lock IDs are, etc.