Re: expose parallel leader in CSV and log_line_prefix
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Michael Paquier <michael@paquier.xyz>, Daniel Gustafsson <daniel@yesql.se>, pgsql-hackers@postgresql.org
Date: 2020-07-10T16:39:09Z
Lists: pgsql-hackers
On Fri, Jul 10, 2020 at 11:11:15AM -0500, Justin Pryzby wrote: > On Fri, Jul 10, 2020 at 05:13:26PM +0200, Julien Rouhaud wrote: > > There's a thinko in the padding handling. It should be dones whether MyProc > > and/or lockGroupLeader is NULL or not, and only if padding was asked, like it's > > done for case 'd' for instance. > > > > Also, the '%k' escape sounds a bit random. Is there any reason why we don't > > use any uppercase character for log_line_prefix? %P could be a better > > alternative, otherwise maybe %g, as GroupLeader/Gather? > > Thanks for looking. %P is a good idea - it's consistent with ps and pkill and > probably other %commands. I also amended the docs. Thanks! So for the leader == NULL case, the AppendStringInfoSpace is a no-op if no padding was asked, so it's probably not worth adding extra code to make it any more obvious. It all looks good to me, I'm marking the patch a ready for committer!
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