* Craig Ringer (cr...@2ndquadrant.com) wrote: > On 14 February 2016 at 08:05, Robert Haas <robertmh...@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
Description: Digital signature