Date: Mon, 20 Jul 2020 23:12:31 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	Julien Rouhaud <rjuju123@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	pgsql-hackers@postgresql.org
Subject: Re: expose parallel leader in CSV and log_line_prefix
Message-ID: <20200721041231.GD5748@telsasoft.com>
References: <20200717205421.GR23581@telsasoft.com>
 <20200717212721.GA3827@alvherre.pgsql>
 <20200717223236.GT23581@telsasoft.com>
 <20200720233048.GC5748@telsasoft.com>
 <20200721035145.GB17300@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200721035145.GB17300@paquier.xyz>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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