public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nico Heller <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Guarantee order of batched pg_advisory_xact_lock
Date: Wed, 11 Feb 2026 21:51:40 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
That's an interesting idea and more likely, yes - I didn't think of that.
So it would probably be better to ORDER BY the hashtextended result
instead of :keysToLock, right?
Hash collisions could therefore not create the [a,b,c] [b,a,c] locking
pattern which obviously deadlocks.
I will check for hash collisions tomorrow, I know all possible keys.
On 2/11/26 22:17, Tom Lane wrote:
> Nico Heller <[email protected]> writes:
>> We use the following bulk query as we sometimes need acquire multiple
>> locks at the same time and want to avoid round-trips to the database:
>> |WITH keys(key) AS (SELECT unnest(:keysToLock)) SELECT
>> pg_advisory_xact_lock(hashtextextended(key, 0)) FROM keys|
>> :keysToLock is a text[] parameter which is pre-sorted in our
>> application. This pre-sorting is done to prevent dead locks when two
>> concurrent transactions try acquire the same advisory locks (e.g.
>> [a,b,c] [b,a,c] can easily deadlock).
>> We thought this would be enough, but we occasionally still run into
>> deadlocks.
> Have you eliminated the possibility that you're getting hash
> collisions? With or without that CTE, I can't see a reason for
> PG to change the order in which the unnest() results are processed,
> so I think you are barking up the wrong tree about where the
> problem is.
>
> regards, tom lane
view thread (3+ messages)
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]
Subject: Re: Guarantee order of batched pg_advisory_xact_lock
In-Reply-To: <[email protected]>
* 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