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. -- Michael
signature.asc
Description: PGP signature
