Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Date
Msg-id 30320.1455488783@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Feb 14, 2016 at 1:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> pgprocno of the specific PGPROC, or of the group leader?  If it's
>> the former, I'm pretty suspicious that there are deadlock and/or
>> linked-list-corruption hazards here.  If it's the latter, at least
>> the comments around this are misleading.

> Leader.  The other way would be nuts.

... and btw, either BecomeLockGroupMember() has got this backwards, or
I'm still fundamentally confused.

Also, after fixing that it would be good to add a comment explaining why
it's not fundamentally unsafe for BecomeLockGroupMember() to examine
leader->pgprocno without having any relevant lock.  AFAICS, that's only
okay because the pgprocno fields are never changed after InitProcGlobal,
even when a PGPROC is recycled.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Patric Bechtel
Date:
Subject: Re: Bool btree_gin index not chosen on equality contraint, but on greater/lower?
Next
From: Tom Lane
Date:
Subject: Re: Bool btree_gin index not chosen on equality contraint, but on greater/lower?