Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
