PostgreSQL on Windows: pending_restart reads false on connections opened after the reload, so we can miss a pending restart #4251

Problem

On PostgreSQL running on Windows, pg_settings.pending_restart reads t only in a session that was already open when the configuration was reloaded. A connection opened after the reload reads f for the same setting, even though the change still waits for a restart.

We collect pending_restart from new connections:

• PerformanceMonitor.Collectors/PgServerConfigCollector.cs collects it from each target's pg_settings. The class comment calls it "a production trap with no symptom".
• The advice reads it back: PerformanceMonitor.Analysis/PgTargetAdvice.Posture.cs:127 and PgTargetAdvice.Buffer.cs:271.
• Darling/PerformanceMonitor.Darling.Service/Mcp/DarlingStoreMetricsReader.cs:237 reads the store's own pg_settings, and the managed store runs on Windows on a Windows install.

So on a Windows-hosted PostgreSQL target, or on the managed store itself, we can report "no restart pending" while one is. Connection pooling makes the answer depend on when the pooled connection was opened.

Evidence

Lane D2 found this on a local rig on 2026-09-25, while designing #4215: PostgreSQL 18.6, the build bundled with Darling, on Windows 11. After a reload that changed a restart-only setting:

• A session open during the reload showed pending_restart = t.
• A new connection showed pending_restart = f.
• From a new connection, pg_file_settings still showed the change, with error = 'setting could not be applied'.

Not checked yet: PostgreSQL on Linux, where new backends are forked from the postmaster. That check is part of the fix.

Fix shape

• Reproduce it on a rig on Windows, and check Linux the same way. If Linux is not affected, say so with the result.
• Where we collect or show pending_restart, also read pg_file_settings (error = 'setting could not be applied', joined on name), and treat either signal as pending. Check the permissions first. The PostgreSQL docs say "By default, the pg_file_settings view can be read only by superusers" (https://www.postgresql.org/docs/current/view-pg-file-settings.html), and a monitoring role usually is not one. Where the view cannot be read, keep today's answer, and say in the output that on a Windows target it can miss a pending restart.
• Pin it with a live test that reloads a restart-only change and then reads it from a fresh connection.

Related

• Managed store sizing: make the derivation platform-aware (Windows 487 cap only on Windows, Linux cgroup limits, commit headroom) and write it to one service-owned config file instead of appended blocks #4215, the managed store sizing design, which must tell when a value it writes needs a restart.
• Managed store: 66–90% of WAL is full-page images, with wal_compression off and checkpoint_timeout at the 5-minute default; together they are worth an estimated half of WAL #4246: the WAL settings it names (wal_compression, checkpoint_timeout) apply on a reload, so this does not affect them.

Tier 4: it affects PostgreSQL on Windows only. No field report so far.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TszxYhJJbTEh4LrZ56NYo3