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 по дате отправления: