Re: Guarantee order of batched pg_advisory_xact_lock

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(dot)heller(at)posteo(dot)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