Re: group locking: incomplete patch, just for discussion - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: group locking: incomplete patch, just for discussion
Date
Msg-id CA+U5nMJpcvC2AhckdXP5spYP0hjEaQhD4G-oMJejT-Fme094vw@mail.gmail.com
Whole thread Raw
In response to Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 3 November 2014 17:00, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs <simon@2ndquadrant.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.

OK, I think I'm happy with this as a general point.

How will we automatically test this code?

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Robert Haas
Date:
Subject: Re: group locking: incomplete patch, just for discussion