On Mon, Feb 11, 2013 at 12:26 PM, Chris Angelico <rosuav@xxxxxxxxx> wrote:
> 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?
>
That should not happen. There are instances when a lock requester will
be promoted ahead of others to avoid deadlock, but in the scenario you
described, no single process will starve forever. See following
comment in ProcSleep() function under src/backend/storage/lmgr/proc.c
which is self-explanatory.
/*
* Determine where to add myself in the wait queue.
*
* Normally I should go at the end of the queue. However, if I already
* hold locks that conflict with the request of any previous waiter, put
* myself in the queue just in front of the first such waiter. This is not
* a necessary step, since deadlock detection would move me to before that
* waiter anyway; but it's relatively cheap to detect such a conflict
* immediately, and avoid delaying till deadlock timeout.
*
* Special case: if I find I should go in front of some waiter, check to
* see if I conflict with already-held locks or the requests before that
* waiter. If not, then just grant myself the requested lock immediately.
* This is the same as the test for immediate grant in LockAcquire, except
* we are only considering the part of the wait queue before my insertion
* point.
*/
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
