On Fri, Dec 27, 2019 at 10:01 AM Sergei Kornilov <s...@zsrv.org> wrote: > > Hello > > > As I understand it, lock group is some infrastructure that is used by > > parallel queries, but could be used for something else too. So if > > more documentation is needed, we should say something like "For now, > > only parallel queries can have a lock group" or something like that. > > If lockGroupLeader will be used in some way for non-parallel query, then the > name leader_pid could be confusing. No? > I treat pg_stat_activity as view for user. We have document somewhere what is > "lock group leader" (excepts README in source tree)? I meant user going to > read documentation, "ok, this field is process ID of the lock group leader, > but what is it?". Expose a leader pid for parallel worker will be clear > improvement for user. And seems lockGroupLeader->pid is exactly this stuff. > Therefore, I would like to see such description and meaning of the field.
I think that not using "parallel" to name this field will help to avoid confusion if the lock group infrastructure is eventually used for something else, but that's only true if indeed we explain what a lock group is. > > The fact that leader_pid == pid for the leader and different for the > > other member should be obvious, I'm not sure that it's worth > > documenting that. > > It may be not obvious that leader_pid is not null in this case. But ok, no > objections. If we adapt lmgr/README to document the group locking, it also addresses this. What do you thing of: The leader_pid is NULL for processes not involved in parallel query. When a process wants to cooperate with parallel workers, it becomes a lock group leader, which means that this field will be valued to its own pid. When a parallel worker starts up, this field will be valued with the leader pid.
