On Sun, Mar 8, 2026 at 2:23 PM <felix(dot)quintgz(at)yahoo(dot)com> wrote:
> What makes me suspect it's a lock on the parent table is the word
> "ShareLock" in the logs. A SELECT ... FOR UPDATE statement shouldn't place
> that type of lock on the table it's selecting.
>
This looks 100% like a normal, multi-row deadlock situation. The CONTEXT
shows it is a row-level problem:
CONTEXT: while locking tuple (7,15) in relation “paiyroll_endpoint”
The ShareLocks are on the transaction, because each backend is waiting for
the other to finish their transaction, and thus release the lock(s) it may
have.
If you implement Tom's suggestion, I think you will find that this is a
classic failing to lock the rows in the same order problem.
Cheers,
Greg