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
