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

From Craig Ringer
Subject Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Date
Msg-id CAMsr+YH2-NKD=7XR3kkQHtHk1w-C+y5Qrsjzq8ni_MtAoaTUvQ@mail.gmail.com
Whole thread Raw
In response to 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
Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
List pgsql-hackers
On 14 February 2016 at 08:05, Robert Haas <robertmhaas@gmail.com> wrote:
 
First, the overall concept here is that processes can either be a
member of a lock group or a member of no lock group.  The concept of a
lock group is formally separate from the concept of a parallel group
created by a ParallelContext, but it is not clear that there will ever
be any other context in which a lock group will be a good idea.  It is
not impossible to imagine: for example, suppose you had a group of
backends that all had TCP client connections, and those processes all
wanted to ingest data and stuff it in a table but without allowing any
unrelated process to touch the table, say because it was going to be
inconsistent during the operation and until indexes were afterwards
rebuilt.

The case that comes to mind for me is in logical decoding, for decoding prepared xacts. Being able to make the prepared xact a member of a "lock group" along with the decoding session's xact may provide a solution to the locking-related challenges there.

I haven't looked closely at what's involved in the decoding prepared xact locking issues yet, just an idea.

To do this it'd have to be possible to add an existing session/xact to a lock group (or make it the leader of a new lock group then join that group). Do you think that's practical with your design?
 
I don't have any plans to implement anything like that but I
felt it was better to keep the concept of a lock group - which is a
group of processes that cooperate so closely that their locks need not
conflict - from the concept of a parallel context - which is a leader
process that is most likely connected to a user plus a bunch of
ephemeral background workers that aren't.  That way, if somebody later
wants to try to reuse the lock grouping stuff for something else,
nothing will get in the way of that; if not, no harm done, but keeping
the two things decoupled is at least easier to understand, IMHO.

Yeah, strong +1

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: extend pgbench expressions with functions
Next
From: Stephen Frost
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl