Re: expose parallel leader in CSV and log_line_prefix

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Julien Rouhaud <rjuju123@gmail.com>, pgsql-hackers@postgresql.org
Date: 2020-07-17T02:41:07Z
Lists: pgsql-hackers
On Fri, Jul 10, 2020 at 01:16:40PM -0400, Alvaro Herrera wrote:
> On 2020-Jul-10, Justin Pryzby wrote:
>> That's what's done.
>> 
>> +             <entry>Process ID of the parallel group leader if this process was
>> +             at some point involved in parallel query, otherwise null.  For a
>> +             parallel group leader itself, this field is set to its own process
>> +             ID.</entry>
> 
> Oh, okay by me then.

Please note that this choice comes from BecomeLockGroupLeader(), where
a leader registers itself in lockGroupLeader, and remains set as such
as long as the process is alive so we would always get a value for a
process once it got involved in parallel query.  This patch is just
doing what we do in pg_stat_get_activity(), with the padding handling.
It is true that this may cause log_line_prefix to be overly verbose in
the case where you keep a lot of sessions alive for long time when
they got all involved at least once in parallel query as most of them
would just refer to their own PID, but I think that it is better to be
consistent with what we do already with pg_stat_activity, as that's
the data present in the PGPROC entries.
--
Michael

Commits

  1. Add %P to log_line_prefix for parallel group leader

  2. Tweak behavior of pg_stat_activity.leader_pid

  3. Add leader_pid to pg_stat_activity