On 15 October 2014 05:03, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
