Re: expose parallel leader in CSV and log_line_prefix
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-17T21:27:21Z
Lists: pgsql-hackers
On 2020-Jul-17, Justin Pryzby wrote: > Ok, but should we then consider changing pg_stat_activity for consistency ? > Probably in v13 to avoid changing it a year later. > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b025f32e0b5d7668daec9bfa957edf3599f4baa8 > > I think the story is that we're exposing to the user a "leader pid" what's > internally called (and used as) the "lock group leader", which for the leader > process is set to its own PID. But I think what we're exposing as leader_pid > will seem like an implementation artifact to users. IMO it *is* an implementation artifact if, as you say, the leader PID remains set after the parallel query is done. I mentioned the pgbouncer case before: if you run a single parallel query, then the process remains a "parallel leader" for days or weeks afterwards even if it hasn't run a parallel query ever since. That doesn't sound great to me. I think it's understandable and OK if there's a small race condition that means you report a process as a leader shortly before or shortly after a parallel query is actually executed. But doing so until backend termination seems confusing as well as useless. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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