From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
Date: | 2016-02-16 20:54:50 |
Message-ID: | 13398.1455656090@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-02-17 01:37:41 | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
Previous Message | Tom Lane | 2016-02-16 20:15:14 | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2016-02-16 21:24:59 | Re: auto_explain sample rate |
Previous Message | Jeff Janes | 2016-02-16 20:38:54 | Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"? |