On 2014-11-20 11:22:37 -0500, Robert Haas wrote: > On Thu, Nov 20, 2014 at 4:21 AM, Jeff Davis <pg...@j-davis.com> wrote: > >> The > >> bad news, to borrow a phrase from Peter Geoghegan, is that it's an > >> unprincipled deadlock; a user confronted with the news that her > >> parallel scan has self-deadlocked will be justifiably dismayed. > > > > You seem to be raising this as a show-stopping problem, and I'm not > > convinced that it is. > > Well, what I'm saying is that at very minimum we have to be able > detect deadlocks, and we have two plausible designs for avoiding that: > > 1. Modify the deadlock detector to know about lock groups. > > 2. Propagate pre-existing locks from the user backend to all the workers. > > I initially proposed #1, but now I think #2 solves more of the > problems for less code.
Except that it opens us up for all kinds of concurrency bugs. I'm pretty strictly set against granting any self exclusive locks en-masse. If we do this by default for all granted locks when starting a worker backend it'll get *so* much harder to reason about correctness. Suddenly locks don't guarantee what they used to anymore. We'll e.g. not be able to rely that a CheckTableNotInUse() + AEL makes it safe to drop/rewrite/whatever a relation - even if that happens in the main backend. Greetings, Andres Freund -- Andres Freund 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
