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

On 14 February 2016 at 08:05, Robert Haas <robertmhaas(at)gmail(dot)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