public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Nico Heller <[email protected]>
Cc: [email protected]
Subject: Re: Guarantee order of batched pg_advisory_xact_lock
Date: Wed, 11 Feb 2026 16:17:54 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

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)  latest in thread

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