Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Date
Msg-id 4950.1455651096@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Catalin Iacob
Date:
Subject: Re: proposal: PL/Pythonu - function ereport