Re: group locking: incomplete patch, just for discussion

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: group locking: incomplete patch, just for discussion
Date: 2014-11-03 18:02:20
Message-ID: CA+U5nMJpcvC2AhckdXP5spYP0hjEaQhD4G-oMJejT-Fme094vw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3 November 2014 17:00, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-03 18:06:39 Re: group locking: incomplete patch, just for discussion
Previous Message Robert Haas 2014-11-03 17:36:58 Re: pgsql: Support frontend-backend protocol communication using a shm_mq.