Part of #2530. Grouped deliberately — each is real but none is the first thing anyone asks, and filing four thin issues would misrepresent their priority against #2538–#2542.
None of the following is collected today (verified by grep across all eight Pg*Collector files):
pg_stat_bgwriter / pg_stat_checkpointer
Checkpoint frequency, requested versus timed checkpoints, buffers written by checkpointer against backend. A checkpoint storm is a real and diagnosable production problem, and checkpoints_req climbing against checkpoints_timed is the classic signal that max_wal_size is too small. Note the view split in PostgreSQL 17 — pg_stat_checkpointer carries what used to be in pg_stat_bgwriter, so this needs a version branch, exactly as PgIoStatsCollector already gates on 16+ for pg_stat_io.
pg_stat_wal
WAL generation rate and full-page-write volume. The write-side counterpart to the I/O stats we already collect, and the thing that explains replication lag and archive pressure.
pg_locks detail
PgBlockingCollector already gives blocker/blocked pairs from pg_stat_activity. What is missing is the lock landscape — mode, granted versus waiting, and locks held without a corresponding wait. Useful when the question is "what is this transaction holding" rather than "who is blocked right now".
pg_buffercache
What is actually resident in shared buffers, by relation. Answers "is this table in memory" directly instead of inferring it from a hit ratio. An extension, and reading it takes a lock on the buffer mapping — so it belongs on demand rather than on a cadence, if at all.
Replication lag in bytes and time
PgReplicationSlotsCollector collects slot state. The lag itself — pg_current_wal_lsn() against confirmed_flush_lsn, and replay_lag from pg_stat_replication — is a distinct measurement, and it is the one that pages someone. A slot can look healthy while a replica is minutes behind.
Suggested handling
Take these individually as capacity allows, splitting each out when someone picks it up. The write-side pair (pg_stat_bgwriter / pg_stat_checkpointer plus pg_stat_wal) is the most coherent first slice, since checkpoints and WAL are one story and share a version-gating problem.
Source: PostgreSQL Wiki — Monitoring.
Part of #2530. Grouped deliberately — each is real but none is the first thing anyone asks, and filing four thin issues would misrepresent their priority against #2538–#2542.
None of the following is collected today (verified by grep across all eight
Pg*Collectorfiles):pg_stat_bgwriter/pg_stat_checkpointerCheckpoint frequency, requested versus timed checkpoints, buffers written by checkpointer against backend. A checkpoint storm is a real and diagnosable production problem, and
checkpoints_reqclimbing againstcheckpoints_timedis the classic signal thatmax_wal_sizeis too small. Note the view split in PostgreSQL 17 —pg_stat_checkpointercarries what used to be inpg_stat_bgwriter, so this needs a version branch, exactly asPgIoStatsCollectoralready gates on 16+ forpg_stat_io.pg_stat_walWAL generation rate and full-page-write volume. The write-side counterpart to the I/O stats we already collect, and the thing that explains replication lag and archive pressure.
pg_locksdetailPgBlockingCollectoralready gives blocker/blocked pairs frompg_stat_activity. What is missing is the lock landscape — mode, granted versus waiting, and locks held without a corresponding wait. Useful when the question is "what is this transaction holding" rather than "who is blocked right now".pg_buffercacheWhat is actually resident in shared buffers, by relation. Answers "is this table in memory" directly instead of inferring it from a hit ratio. An extension, and reading it takes a lock on the buffer mapping — so it belongs on demand rather than on a cadence, if at all.
Replication lag in bytes and time
PgReplicationSlotsCollectorcollects slot state. The lag itself —pg_current_wal_lsn()againstconfirmed_flush_lsn, andreplay_lagfrompg_stat_replication— is a distinct measurement, and it is the one that pages someone. A slot can look healthy while a replica is minutes behind.Suggested handling
Take these individually as capacity allows, splitting each out when someone picks it up. The write-side pair (
pg_stat_bgwriter/pg_stat_checkpointerpluspg_stat_wal) is the most coherent first slice, since checkpoints and WAL are one story and share a version-gating problem.Source: PostgreSQL Wiki — Monitoring.