Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
| От | Tom Lane |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
| Дата | |
| Msg-id | 30320.1455488783@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Re: [COMMITTERS] pgsql: Introduce group locking to
prevent parallel processes from deadl
|
| Список | 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 по дате отправления: