Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
От | Robert Haas |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
Дата | |
Msg-id | CA+Tgmob6OM-2F+nzJyY22D0nF3WDEBvVzHgFtCnP89K=vkGcQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
Список | pgsql-hackers |
On Sun, Feb 14, 2016 at 5:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Yeah, you're right. Attached is a draft patch that tries to clean up that and a bunch of other things that you raised. It hasn't really been tested yet, so it might be buggy; I wrote it during my long plane flight. Fixes include: 1. It removes the groupLeader flag from PGPROC. You're right: we don't need it. 2. It fixes this problem with BecomeLockGroupMember(). You're right: the old way was backwards. 3. It fixes TopoSort() to be less inefficient by checking whether the EDGE is for the correct lock before doing anything else. I realized this while updating comments related to EDGE. 4. It adds some text to the lmgr README. 5. It reflows the existing text in the lmgr README to fit within 80 columns. 6. It adjusts some other comments. Possibly this should be broken up into multiple patches, but I'm just sending it along all together for now. > 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. I am sort of disinclined to think that this needs a comment. Do we really have a comment every other place that pgprocno is referenced without a lock? Or maybe there are none, but it seems like overkill to me to comment on that at every site of use. Better to comment on the pgprocno definition itself and say "never changes". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: