Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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"?