public inbox for [email protected]
help / color / mirror / Atom feedFrom: Greg Sabino Mullane <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()
Date: Sun, 8 Mar 2026 18:08:01 -0400
Message-ID: <CAKAnmmKD2kxF6pD3c5eFhJZ+TMogRS9dHcMWbmiZs2Vn=XvZ0g@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAHAc2jd=x-6hM=CoEYOaJ6ST5p-nGkTxDmh=PrwxacnkUp=31A@mail.gmail.com>
<[email protected]>
<CAHAc2jeME7KPPP3TgP9qWC5LMTOs4gYTEJ1MBDwnj7J2EvJTdA@mail.gmail.com>
<[email protected]>
On Sun, Mar 8, 2026 at 2:23 PM <[email protected]> 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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()
In-Reply-To: <CAKAnmmKD2kxF6pD3c5eFhJZ+TMogRS9dHcMWbmiZs2Vn=XvZ0g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox