Skip to content
dbexplore

PostgreSQL 16

What PostgreSQL 16 changed in monitoring

Released 14 September 2023, supported until 9 November 2028. 7 pages so far, each verified against PostgreSQL 16.15.

PostgreSQL 16 added the view that most of the later monitoring changes were built on. Before it, the question of who was doing the physical I/O on a server had to be answered by subtraction: total reads from one view, checkpointer and background writer activity from another, and the remainder attributed to backends by inference. The new view answers it directly, one row per kind of process, per kind of object, per context in which the buffer was used, with counts, and with timing when timing is switched on. Two other counters landed in the same release that change how a stale table is diagnosed: the per-table statistics gained the time of the last sequential and index scan, and a column counting updates that had to find room on a new page. Logical replication learned to run from a standby, which moves load off primaries but adds a slot to watch. Because 16 added rather than moved, the pages here mostly show an after with no before, and say so; the exception is where the new view made a workaround obsolete.

The release notes for this version are at postgresql.org; every page below cites the section it draws on by name. The hub for every supported version carries the support calendar.

  1. PostgreSQL 16 breaks: none

    pg_stat_io and the end of I/O by subtraction

    For anyone who has tried to work out whether the checkpointer, the background writer or the backends are doing the writing on a busy cluster.

  2. PostgreSQL 16 breaks: none

    The timestamp that dates an unused index

    For anyone who has kept a baseline of idx_scan for six weeks in order to answer a question the server can now answer directly.

  3. PostgreSQL 16 breaks: none

    The update counter fillfactor was waiting for

    For anyone who has tuned fillfactor on a hot table and had no way to tell whether it worked.

  4. PostgreSQL 16 breaks: none

    Reading a backend's subtransaction cache

    For anyone who has met a cluster that slowed down in proportion to how many savepoints its application opened.

  5. PostgreSQL 16 breaks: none

    The slot column that is null when it matters

    For anyone about to move logical replication off a busy primary and onto the replica that was sitting idle.

  6. PostgreSQL 16 breaks: none

    The subscription reset that did nothing

    For anyone whose replication runbook starts by clearing the error counters so the next failure is unambiguous.

  7. PostgreSQL 16 breaks: silent

    The temp reads that were really extends

    For anyone who keeps a cache hit ratio on a dashboard and is about to upgrade the cluster underneath it.

Grep your monitoring configuration for these

Every view, column and setting the pages above touch, in one list. A hit in an exporter query file, a dashboard definition or an alert rule is a place to read the page that names it.

  • apply_error_count
  • backend_type
  • blk_read_time
  • blk_write_time
  • blks_hit
  • blks_read
  • conflicting
  • context
  • evictions
  • extends
  • fillfactor
  • hot_standby_feedback
  • idx_scan
  • last_idx_scan
  • last_seq_scan
  • n_tup_hot_upd
  • n_tup_newpage_upd
  • n_tup_upd
  • pg_create_logical_replication_slot
  • pg_log_standby_snapshot
  • pg_replication_slots
  • pg_stat_all_indexes
  • pg_stat_all_tables
  • pg_stat_clear_snapshot
  • pg_stat_database
  • pg_stat_database.blks_read
  • pg_stat_get_backend_idset
  • pg_stat_get_backend_pid
  • pg_stat_get_backend_subxact
  • pg_stat_io
  • pg_stat_reset_single_table_counters
  • pg_stat_reset_subscription_stats
  • pg_stat_subscription_stats
  • pg_stat_user_tables
  • pg_subscription
  • read_time
  • reads
  • seq_scan
  • slot_type
  • stats_reset
  • subxact_count
  • subxact_overflowed
  • sync_error_count
  • temp_buffers
  • wal_status
  • write_time
  • writes

The failure modes these changes touch are in the reference guides; the terms the release notes assume are in the glossary. Across a fleet, the version is what decides where a signal lives, which is why engine discovery establishes it first.

Put every Postgres you run on autopilot.

We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.

Request early access Book a demo