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
-
Add %P to log_line_prefix for parallel group leader
- b8fdee7d0ca8 14.0 landed
-
Tweak behavior of pg_stat_activity.leader_pid
- 21b0055359f0 13.0 landed
- 11a68e4b53ff 14.0 landed
-
Add leader_pid to pg_stat_activity
- b025f32e0b5d 13.0 cited