Every service restart raises a false Store Checkpointer Pressure warning: PostgreSQL counts the shutdown checkpoint as requested, and a monitored target's restart reads as a WAL-forced checkpoint the same way #3955

What happens

PostgreSQL counts a shutdown checkpoint in pg_stat_checkpointer.num_requested, and the counter survives the restart. #3783's Store Checkpointer Pressure alert treats any requested checkpoint as proof the store outran max_wal_size ("one WAL-forced checkpoint in an hour says the store outran max_wal_size"). So every service restart raises a false Warning at the first self-metrics run after the start.

Measured on a scratch 18.6 cluster. num_timed | num_requested | num_done after a fresh initdb, then after each fast stop and start:

fresh:            0|0|0
after 1 restart:  0|1|0
after 2 restarts: 0|2|0

The server log shows only checkpoint starting: shutdown immediate lines. Nothing was WAL-triggered.

Seen live on DARLING01, 2026-09-22 17:21 local. "ALERT TRIGGERED [Warning] Store Checkpointer Pressure on Monitor Store: store checkpointer: 2 WAL-forced checkpoint(s) in the last 7.1 min". The store's server log for that window has one timed checkpoint and two shutdown immediate checkpoints: the service stop, and the stop of the #3908 update's private-port start. It has no checkpoint starting: wal at all.

Why it matters now

Every Darling host restarts when it upgrades. From Thursday's release (3.9, #3908), the first start also stops the store once more after moving TimescaleDB. So every upgraded host gets a Warning that names a store-sizing problem it does not have, at the moment an operator is watching most closely.

The same counter, other readers

num_requested deltas also feed:

• the monitored-target write stats: PgTargetFactCollector.Write.cs (num_requested - LAG(num_requested)), DarlingPgWriteStatsReader, and DarlingMcpPgServerStateTools' pct_checkpoints_requested;
• the store metrics reader.

A monitored PostgreSQL server's restart reads as a WAL-forced checkpoint there too, and on PostgreSQL 16 and earlier the same holds for pg_stat_bgwriter.checkpoints_req.

Fix direction

• An interval that spans a postmaster restart cannot say how many of its requested checkpoints were shutdowns. The previous sample predates pg_postmaster_start_time() in that case.
• For such an interval, the requested-checkpoint figure is unknown. Record it as NULL or excluded, and let no alert or finding judge it.
• The timed count and the write and sync phases are unaffected.
• Record whatever lets the reader tell, for example the postmaster start time beside the sample, so the readers can apply the same rule.
• Tests: an interval spanning a restart does not fire the alert, and one without a restart still does. Red-watch both.