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
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 |
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? |