Order of granting with many waiting on one lock - Mailing list pgsql-general

From Chris Angelico
Subject Order of granting with many waiting on one lock
Date
Msg-id CAPTjJmqsAEm=jpv2KJ=Uub=ZisXEARCMzDR47qedzks7RRjdJA@mail.gmail.com
Whole thread Raw
Responses Re: Order of granting with many waiting on one lock  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-general
I've poked around a bit with my good friend Google Search and come up
blank, and I'm fairly sure this is something that shouldn't be relied
upon, but it's a point of curiosity.

Suppose I have twenty processes that all request the same lock. (I'm
working with pg_advisory_xact_lock, but any exclusive lock should do.)
One of them will obtain it, the others will block. The winner then
holds the lock for a second or so, then commits (releasing the lock),
then goes back and requests it again. Rinse and repeat. Yes, I know
this sounds ridiculous, but it's a simplified version of the
worst-case scenario in one of our systems.

The question is: How is it decided which process will get the lock
when the previous one commits? Is there any sort of guarantee that all
the processes will eventually get a turn, or could two processes
handball the lock to each other and play keepings-off against the
other eighteen?

Chris Angelico

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: REINDEX deadlock - Postgresql -9.1
Next
From: Pavan Deolasee
Date:
Subject: Re: Order of granting with many waiting on one lock