> I don't think that'd help at all? The problem here is the lock upgrade
from RowExclusiveLock to the exclusive lock, and that'll not be fixed by
that proposal?
The problem is that the RowExclusiveLock is being aquired in one session
before the Exclusive lock, even though the LOCK TABLE statement is
physically first in the SQL function.
Because the locks are being acquired out-of-order, deadlocks become possible
as another session tries to escalate the lock and waits, then the first
session tries to escalate it's own lock and deadlocks.
Normally this is prevented by acquiring the most restrictive lock first, but
with a SQL-language function (unlike plpgsql for example) this is not
possible.
This is how I understand Tom's initial reply, is that not right?
