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 4950.1455651096@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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Yeah, you're right.  Attached is a draft patch that tries to clean up
> that and a bunch of other things that you raised.

I've been reviewing this patch, and I had a question: why do we need to
bother with a lockGroupLeaderIdentifier field?  It seems totally redundant
with the leader's pid field, ie, why doesn't BecomeLockGroupMember simply
compare leader->pid with the PID it's passed?  For some more safety, it
could also verify that leader->lockGroupLeader == leader; but I don't
see what the extra field is buying us.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Freeze avoidance of very large table.
Следующее
От: Catalin Iacob
Дата:
Сообщение: Re: proposal: PL/Pythonu - function ereport