Re: group locking: incomplete patch, just for discussion

On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> The main question is still why any of this is necessary? If we are
> only acquiring fast path locks in workers, what need is there for any
> of this? The leader and workers never conflict with each other, so why
> would they ever wait for each other (except at a point where they are
> actively transferring data), which is the necessary pre-condition for
> a deadlock?
>
> Yes, running a command with a conflicting lock would disrupt the start
> of a parallel operation, but as I said above, the deadlock detector
> will eventually see that and re-arrange us so there is no deadlock.
>
> The only need I can see is if one of the workers/leader requests a
> Strong lock on an object, someone else requests a conflicting lock on
> that object and then we perform a parallel operation ourselves. We
> could easily solve that by saying that you can't go parallel if you
> hold a strong lock AND that workers can't take anything higher than
> RowShareLock, like HS backends. That's good enough for now.

That would be enough to keep the parallel group from deadlocking with
itself, but it wouldn't be enough to prevent deadlock with other
processes, which is the scenario that actually worries me a lot more.
In particular, I'm worried about deadlocks where some other process
gets sandwiched between two processes from the same parallel group.
That is, let A1 be a parallel group leader and A2 be a process from
the same parallel group, and let B be an unrelated process. I'm
worried about the situation where A2 waits for B which waits for A1
which (outside the view of the deadlock detector) waits for A2. All
that can happen even if the parallel backends hold no strong locks,
because B can hold strong locks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company