* Craig Ringer (craig@2ndquadrant.com) wrote:
> 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 was thinking this would be the way to address the current issues with
parallel pg_dump and having a shared snpashot.
> I haven't looked closely at what's involved in the decoding prepared xact
> locking issues yet, just an idea.
Yeah, don't have much more than it being an idea to use this for the
pg_dump case. I do know that's a case which has been brought up a
couple of times before.
> 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?
Seems like the same question applies to the pg_dump case.
Thanks!
Stephen