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.
