Re: group locking: incomplete patch, just for discussion

On 15 October 2014 05:03, Robert Haas <robertmhaas(at)gmail(dot)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