On Tue, Jul 21, 2020 at 6:33 AM Michael Paquier <michael@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.