On Tue, Jul 21, 2020 at 6:33 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Mon, Jul 20, 2020 at 11:12:31PM -0500, Justin Pryzby wrote: > > On Tue, Jul 21, 2020 at 12:51:45PM +0900, Michael Paquier wrote: > > 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). > > Hmm. Not sure. This sounds like material for a separate and larger > patch. > > >> <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> > > > > 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. > > I preferred mine, and it seems to me that the first sentence of the > previous patch covers already both things mentioned in your sentence. > It also seems to me that it is an important thing to directly outline > that this field remains NULL for group leaders.
I agree that Michael's version seems less error prone and makes everything crystal clear, so +1 for it.
