Add pg_stat_kind_info system view

First seen: 2026-04-30 17:47:59+00:00 · Messages: 5 · Participants: 2

Latest Update

2026-06-04 · claude-opus-4-6

Incremental Update: Paquier Concedes on Callbacks, Refines shared_size Semantics

Michael Paquier responds with a concession on the callback columns and a new technical suggestion about shared_size NULL semantics.

Key Developments

  1. Callback columns dropped: Paquier explicitly backs down from his earlier proposal to expose callback existence booleans at the SQL level. He acknowledges there's "currently no internal mechanism" to enforce consistency of built-in stats kinds' flags and callbacks, and says "Perhaps it is not worth bothering at the end." He's fine keeping the published data minimal. This resolves the open design disagreement from the previous round in Partin's favor.

  2. Minimum agreed column set: Paquier confirms that fixed_amount, write_to_file, and accessed_across_databases "feel like useful additions" — establishing these as the consensus set of metadata columns beyond the original schema.

  3. New shared_size NULL semantics proposal: Paquier suggests that shared_size should be NULL (rather than 0) for built-in fixed-sized stats kinds where the size isn't explicitly known at the kind registration level. He draws a distinction: custom fixed-sized stats kinds do set shared_size at registration (because extensions must declare their memory needs), but built-in fixed-sized kinds don't — their memory is allocated through a different mechanism (static offsets in the shared stats control structure). Using NULL rather than 0 avoids the misleading implication that these kinds consume no shared memory.

Technical Significance

The shared_size NULL semantics refinement is architecturally meaningful. It reflects the deeper asymmetry between how built-in and custom fixed-sized stats kinds manage memory:

Using NULL for built-in fixed-sized kinds correctly communicates "not applicable through this mechanism" rather than "zero bytes" — a more honest representation of the internal architecture.

Status

The design is converging. Paquier has yielded on the callback columns, confirmed the metadata column additions, and offered one refinement to NULL semantics. A v2 patch from Partin incorporating these decisions is the next expected action.

History (1 prior analysis)
2026-06-01 · claude-opus-4-6

Incremental Update: Tristan Partin's Response to Paquier's Review

Tristan Partin responds to Michael Paquier's review, agreeing with some suggestions while pushing back on others.

Key Decisions

  1. Test stability fix accepted: Partin agrees to filter on builtin = true in regression tests and remove the builtin column from the SELECT list in test queries, acknowledging he hadn't considered the installcheck problem with custom extensions loaded.

  2. Metadata columns accepted: Partin agrees to expose the following additional columns in v2:

    • fixed_amount
    • accessed_across_databases
    • write_to_file
    • snapshot_ctl_off
    • shared_ctl_off
    • shared_data_off
    • shared_data_len
    • pending_size

  3. Callback existence columns questioned: Partin pushes back on exposing boolean columns for callback registration. His argument: the invariants that callbacks enforce (e.g., certain callbacks only valid for fixed-numbered kinds) could instead be checked at registration time in pgstat_register_kind(), similar to the existing validation code that already checks shared_size and track_entry_count for fixed-numbered kinds. He's asking: why expose callbacks at SQL level when the C-level registration function could simply reject invalid configurations earlier?

Technical Significance

Partin's counter-proposal about callbacks represents a meaningful design question: should invariant enforcement happen at registration time (C-level) or at observation time (SQL-level)? The registration-time approach is fail-fast and prevents invalid states from ever existing. The SQL-level approach enables ongoing verification and regression testing of both built-in and extension stats kinds. These aren't mutually exclusive — you could do both — but Partin is implicitly asking whether the SQL view's role should be "monitoring/introspection" rather than "invariant enforcement."

This also reveals that the existing pgstat_register_kind() validation is incomplete — it only checks a subset of the documented invariants. Partin's suggestion to extend those C-level checks is independently valuable regardless of the view's final column set.

Status

v2 patch not yet posted. Partin is waiting for further discussion resolution before submitting.