Refresh PostgreSQL statistics snapshots before diagnosing a stalled counter

Check the statistics session before treating an unchanged PostgreSQL counter as a stalled service.

Source facts

PostgreSQL 17 can cache accessed cumulative statistics until the end of the current transaction. Repeating a statistics query inside that transaction can therefore return unchanged values even while activity continues. Current-query information has related transaction snapshot behavior. The stats_fetch_consistency setting controls statistics fetching, and pg_stat_clear_snapshot discards the transaction’s cached values or snapshot. Cumulative totals can also lag ongoing activity because processes flush statistics as they go idle, rather than continuously during every operation.

Source: PostgreSQL 17 — Cumulative Statistics.

Applicability

This applies to PostgreSQL 17 statistics-based troubleshooting. It concerns observation semantics and does not show that an application, collector, or database has actually stopped making progress.

DSE recommendation

DSE recommends checking the monitoring session’s transaction state before escalating a frozen-looking counter. Record which view is being read, its sampling interval, and whether the connection remains in a long transaction. Use a deliberate refresh method suitable for the collector instead of repeatedly reopening unrelated services. Keep sampling semantics in the dashboard notes so a future operator can distinguish a stable observation snapshot from a real lack of work. Preserve the original diagnostic timestamps.

Verification

In a test database, compare repeated statistics reads within one transaction with reads after ending it or clearing the snapshot. Generate a small known workload from another session. Confirm the collector’s results change as expected and document any normal flush delay separately from an actual collection failure.

Official reference

PostgreSQL 17 — Cumulative Statistics. Reviewed October 15, 2026.