Tweak behavior of pg_stat_activity.leader_pid
authorMichael Paquier <michael@paquier.xyz>
Sun, 26 Jul 2020 07:32:11 +0000 (16:32 +0900)
committerMichael Paquier <michael@paquier.xyz>
Sun, 26 Jul 2020 07:32:11 +0000 (16:32 +0900)
commit11a68e4b53ffccf336a2faf5fa380acda28e880b
treeed95c0ae0155e1030afd6689c9a5586463d22fee
parent15e441972276e95639f8c3d9f5f66c2318fe9348
Tweak behavior of pg_stat_activity.leader_pid

The initial implementation of leader_pid in pg_stat_activity added by
b025f32 took the approach to strictly print what a PGPROC entry
includes.  In short, if a backend has been involved in parallel query at
least once, leader_pid would remain set as long as the backend is alive.
For a parallel group leader, this means that the field would always be
set after it participated at least once in parallel query, and after
more discussions this could be confusing if using for example a
connection pooler.

This commit changes the data printed so as leader_pid becomes always
NULL for a parallel group leader, showing up a non-NULL value only for
the parallel workers, and actually as long as a parallel query is
running as workers are shut down once the query has completed.

This does not change the definition of any catalog, so no catalog bump
is needed.  Per discussion with Justin Pryzby, Álvaro Herrera, Julien
Rouhaud and me.

Discussion: https://postgr.es/m/20200721035145.GB17300@paquier.xyz
Backpatch-through: 13
doc/src/sgml/monitoring.sgml
src/backend/utils/adt/pgstatfuncs.c