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 | 13398.1455656090@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 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: > 1. It removes the groupLeader flag from PGPROC. You're right: we don't need it. It occurs to me that this claim is bogus: > We institute a further coding rule that a process cannot join or leave a lock > group while owning any PROCLOCK. Therefore, given a lock manager lock > sufficient to examine PROCLOCK *proclock, it also safe to examine > proclock->tag.myProc->lockGroupLeader (but not the other fields mentioned in > the previous paragraph). Yes, we can legislate that workers have to join before taking any lock, and if processes only leave the group at death then that end of it is not a problem either; but it is patently not the case that a process will hold no locks when it calls BecomeLockGroupLeader(). We may be able to salvage this simplification anyway, but it will require a tighter specification of when it's safe to look at proclock->tag.myProc->lockGroupLeader. Another possibility is to forget about executor-time BecomeLockGroupLeader(), and just say that any process that isn't a worker always becomes its own group leader at startup. Then the above para is true as written. I don't know what downsides this might have; do your changes in the lock manager try to optimize the null-lockGroupLeader case? regards, tom lane
В списке pgsql-hackers по дате отправления: