On Tue, Jul 21, 2020 at 12:51:45PM +0900, Michael Paquier wrote: > And I'd rather keep the simple suggestion of upthread to leave the > field as NULL for the parallel group leader with a PID match but not a > backend type check so as this could be useful for other types of > processes.
The documentation could talk about either: 1) "lock group leader" - low-level, raw view of the internal data structure (with a secondary mention that "for a parallel process, this is its parallel leader). 2) "parallel leaders" high-level, user-facing, "cooked" view; Right now it doesn't matter, but it seems that if we document the high-level "parallel leader", then we don't need to accomodate future uses (at least until the future happens). > diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml > index dc49177c78..15c598b2a5 100644 > --- a/doc/src/sgml/monitoring.sgml > +++ b/doc/src/sgml/monitoring.sgml > @@ -687,12 +687,9 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss > 11:34 0:00 postgres: ser > <structfield>leader_pid</structfield> <type>integer</type> > </para> > <para> > - Process ID of the parallel group leader if this process is or > - has been involved in parallel query, or null. This field is set > - when a process wants to cooperate with parallel workers, and > - remains set as long as the process exists. For a parallel group > leader, > - this field is set to its own process ID. For a parallel worker, > - this field is set to the process ID of the parallel group leader. > + Process ID of the parallel group leader if this process is involved > + in parallel query, or null. For a parallel group leader, this field > + is <literal>NULL</literal>. > </para></entry> > </row> FWIW , I prefer something like my earlier phrase: | For a parallel worker, this is the Process ID of its leader process. Null | for processes which are not parallel workers. -- Justin
