Re: Guarantee order of batched pg_advisory_xact_lock - Mailing list pgsql-general

From Nico Heller
Subject Re: Guarantee order of batched pg_advisory_xact_lock
Date
Msg-id 87ca8c2c-6826-44d1-8a31-a5f793a2729e@posteo.de
Whole thread Raw
In response to Re: Guarantee order of batched pg_advisory_xact_lock  (Nico Heller <nico.heller@posteo.de>)
Responses Re: Guarantee order of batched pg_advisory_xact_lock
List pgsql-general

Does anyone have any idea what the root cause of my issue is? I appreciate any insight.
As I said, hash collisions can be rules out, sadly.

On 2/12/26 12:18, Nico Heller wrote:

I just checked for hash collisions with the following query today:

SELECT COUNT(*), hashtextextended(key, 0) FROM
(
  SELECT key FROM table1
  UNION
  SELECT key FROM table2
  UNION
  ...
) keys (key)
GROUP BY hashtextextended(key, 0)
HAVING COUNT(*) > 1

Where table1, table2, ... are all the tables we are acquire keys from to use for the mentioned query.

Sadly, no results were returned. Thus, I can rule out hash collisions.

Any other thoughts? Here is an error log from the JDBC driver:


org.postgresql.util.PSQLException: ERROR: deadlock detected Detail: Process 60780 waits for ExclusiveLock on advisory lock [24605,3030106527,494580150,1]; blocked by process 65280.
                                                                                                                 Process 65280 waits for ExclusiveLock on advisory lock [24605,1321834016,1311356115,1]; blocked by process 60780.



On 2/11/26 23:49, Tom Lane wrote:
Nico Heller <nico.heller@posteo.de> writes:
So it would probably be better to ORDER BY the hashtextended result 
instead of :keysToLock, right?
Yeah, that seems like it'd work, if you have no other dependencies
on the locking order.
			regards, tom lane

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: pgbouncer transaction pool mode issue for prepared statements
Next
From: Durgamahesh Manne
Date:
Subject: Re: pgbouncer transaction pool mode issue for prepared statements