On 15 October 2014 05:03, Robert Haas <robertmhaas@gmail.com> wrote:
> At least to me, that simple scenario is clear-cut[1], but what do we
> do in more complicated situations? For example, suppose backends A
> and B are members of the same locking group. A locks a relation with
> AccessShareLock, an unrelated process X queues up waiting for an
> AccessExclusiveLock, and then B also requests AccessShareLock. The
> normal behavior here is that B should wait for X to go first, but here
> that's a problem. If A is the user backend and B is a worker backend,
> A will eventually wait for B, which is waiting for X, which is waiting
> for A: deadlock.
Yes, deadlock.
My understanding would be that the lead process would wait on a latch,
not a heavyweight lock. So it would never perform a deadlock
detection. Which leaves only X and B to perform the deadlock check.
Are you aware that the deadlock detector will reorder the lock queue,
if that presents a possible solution to the deadlock?
Would the above example not be resolved simply with the existing code?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
