Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Date: 2016-02-14 22:26:23
Message-ID: 30320.1455488783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Feb 14, 2016 at 1:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Noah Misch 2016-02-15 07:38:18 pgsql: Replace broken link in comment.
Previous Message Tom Lane 2016-02-14 22:05:04 Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-14 22:53:30 Re: Bool btree_gin index not chosen on equality contraint, but on greater/lower?
Previous Message Patric Bechtel 2016-02-14 22:11:58 Re: Bool btree_gin index not chosen on equality contraint, but on greater/lower?