pgsql: Tweak behavior of pg_stat_activity.leader_pid - Mailing list pgsql-committers

From Michael Paquier
Subject pgsql: Tweak behavior of pg_stat_activity.leader_pid
Date
Msg-id E1jzb9i-0001bJ-8w@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
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

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/21b0055359f036e3ba22402d14536431dd39242e

Modified Files
--------------
doc/src/sgml/monitoring.sgml        | 9 +++------
src/backend/utils/adt/pgstatfuncs.c | 8 +++++++-
2 files changed, 10 insertions(+), 7 deletions(-)


pgsql-committers by date:

Previous
From: Noah Misch
Date:
Subject: pgsql: Use RAND_poll() for seeding randomness after fork().
Next
From: David Rowley
Date:
Subject: pgsql: Allocate consecutive blocks during parallel seqscans