| From: | Nico Heller <nico(dot)heller(at)posteo(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Guarantee order of batched pg_advisory_xact_lock |
| Date: | 2026-02-12 11:18:34 |
| Message-ID: | 777cfa1c-fd1f-479f-b9b8-217b0f7a40b7@posteo.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2026-02-12 14:47:39 | Re: Guarantee order of batched pg_advisory_xact_lock |
| Previous Message | Tom Lane | 2026-02-11 22:49:57 | Re: Guarantee order of batched pg_advisory_xact_lock |