get_pg_server_config counted the page and called it the server: non_default_count is now the snapshot's, computed above the cap, truncated is observed off a limit + 1 fetch, and its three sibling pages stop inferring truncation from a full page (#3653 A3 residue)

[erikdarlingdata]

Part of #3653 (the get_pg_server_config A3 residue, from #3541). Does not close it.

The lie

get_pg_server_config published two numbers about the server that were numbers about the page.

non_default_count was rows.Count(r => !r.IsDefault) — a count over the rows the reader had FETCHED, which the caller's limit had already cut. At limit = 25 against a server with forty chosen settings it said 25, and an agent that cannot see the code read "25 settings differ from default" as a fact about the snapshot. The number moved with the page size, which is the one thing a count of the server must never do.

truncated was rows.Count >= limit — the inference #3594 named and every other honest page in the repository has since replaced: a page that happens to be exactly limit long cannot tell "that was all of them" from "there was at least one more", and the flag said more either way. On this tool the flag was worse than uninformative, because the default view fetched the WHOLE snapshot at limit and filtered the defaults out in C# afterwards. A server has several hundred parameters and the default limit is 100, so truncated was true on nearly every default-view call even when every chosen setting was on the page. A flag that is always up says nothing.

Three sibling tools in the same file — get_pg_extensions (~175), get_pg_lock_stats (~423), get_pg_server_config_changes (~716) — carried the same >= limit inference and published it. get_pg_extensions and get_pg_lock_stats also WITHHOLD their state totals when truncated is true, so on a window holding exactly limit groups they withheld figures that were complete.

The fix

The reader carries the snapshot's count on the row statement (DarlingPgServerConfigReader.CurrentConfigSql): COUNT(*) FILTER (WHERE coalesce(c.source, 'default') <> 'default') OVER ()::int AS snapshot_non_default_count — the #3613 idiom. A window aggregate over the filtered result, which PostgreSQL evaluates before ORDER BY and LIMIT, so it is the same figure at limit = 5 and limit = 500, and the same figure whether or not defaults are included (the FILTER counts only non-default rows, and every non-default row is in both populations). The FILTER's predicate is the SAME expression the row's is_default column is read from, so the count is provably of the flag the rows report. A new PgConfigPage(Rows, SnapshotNonDefaultCount) record and GetCurrentConfigPageAsync carry it; GetCurrentConfigAsync (the Viewer's grid) is unchanged in signature and returns .Rows with every setting, as before.

The include_defaults filter moved into the statement ($2::boolean), so the cap cuts the population the caller asked for and truncated means "that population held more than limit". A pending-restart row stays in the default view whatever its source: it is the row that says the file and the running server disagree, the ordering already put it first for that reason, and the old shape counted it in pending_restart_settings while hiding it from settings. That is the one visible behaviour change beyond the counts: a pending-restart setting whose running value is still the default now appears in the default-view settings list with is_default = true, pending_restart = true. It is not counted in non_default_count — it is not a chosen setting yet.

The tool fetches limit + 1 and observes. truncated = page.Rows.Count > limit, the page is Take(limit), and the payload publishes three counts with their denominator in their names: settings_returned (the page), non_default_count (the snapshot), non_default_returned (the snapshot's chosen settings on THIS page — when it equals non_default_count, every chosen setting is here whatever truncated says about the rest). The description states which denominator each uses, in the A7 vocabulary: "THE PAGE IS BOUNDED BY limit … COUNTS ARE OF THE SNAPSHOT, NOT OF THE PAGE".

The three siblings fetch limit + 1 and observe. Their readers already bound the cap as a parameter, so it is the tool-side change only; every downstream consumer (the extension tool's PgCappedRead.Classify, per-database completeness grouping, the lock tool's ungranted count) reads the trimmed page as before.

What it does NOT do

• It does not rename extension_count / lock_count / change_count to *_returned. They are page counts under a neutral noun, not total_*, and server-tabs.js may read them; renaming is a web-tile change outside this lane.
• It does not touch PgCappedRead's ReturnedRows < Limit → Complete test. That classifier is documented as deliberately pessimistic ("the direction to be wrong in") and has its own two test files; a page of exactly limit rows with nothing behind it still classifies Partial there. Noted, not changed.
• Three MORE Darling tools in OTHER files carry the same truncated = rows.Count >= limit: DarlingMcpPgDeadlockTools.cs:82, DarlingMcpPgPlanTools.cs:210 (inside BuildReadinessJson, which has its own wire-shape tests), DarlingMcpPgIndexTools.cs:150 (which also hands rows.Count to the coverage verdict). Each needs its own diff against its own pins; reported on Brains-review campaign: deferred structural residue (from #3538 / #3539 / #3540 / #3541) #3653 rather than folded in here.
• No settings_in_snapshot total. The FILTERed count is the figure the finding named; a second window count is a separate decision.

Tests

McpPageContractTests gains a Darling-only section (Lite has no PostgreSQL tools, so — like the A7 roster — no twin-parity arm):

• EveryPgServerStatePage_ObservesTruncation_AndNeverInfersIt — the four bodies never match TruncationInferred, each matches an observed form and asks for limit + 1; and the WHOLE file is swept, so a fifth paged tool added to it inherits the rule.
• EveryPgServerStateRead_BindsItsCapAsAParameter_NeverALiteral — the four reader consts end in a parameterised LIMIT.
• PgServerConfig_CountsTheSnapshotOnTheRowStatement_AndFiltersInTheQuery — the COUNT(*) FILTER … OVER () column sits above the ORDER BY, its predicate is the is_default expression, $2::boolean and the pending-restart keep are in the statement, the body reads page.SnapshotNonDefaultCount, and no .Where( remains over the rows beyond the pending-restart name list.
• PgServerConfig_NamesItsDenominators_InItsDescription.
• McpPageContractLivePostgresTests.PgServerConfig_CountsTheSnapshotNotThePage_AgainstDevPostgres — seeds one snapshot (four chosen, two default, one session-scoped row) plus an OLDER snapshot with eight chosen settings the newest-snapshot anchor must ignore. Default view, population 4: limit = 3 truncated with non_default_count = 4 (the old shape said 3), limit = 4 NOT truncated (the >= limit case). include_defaults, population 6: limit = 5 truncated, limit = 6 not, non_default_count = 4 on both. A pending-restart default-source row: population 5, snapshot count holds at 4, the row leads the page.

Executed on this Mac via the mactest harness (net10.0 xunit.v3, AssemblyName=Darling.Tests) against timescale/timescaledb:2.28.1-pg18: McpPageContractTests, PgServerConfigTests, McpPageContractLivePostgresTests, McpLatestSnapshotStampTests, DarlingPgReadSqlParsesLiveTests (parse analysis of every shipped reader SQL — the $2::boolean bind is what this catches), PgCappedReadSurfaceTests, DarlingCappedReadLivePostgresTests — 92 tests, 0 failed, 0 skipped. Positive control: with the tool's truncated reverted to >= limit the live test fails on the limit = 4 page (Assert.False … Actual: True). Service, Storage, Viewer and Darling.Tests build -c Release -p:EnableWindowsTargeting=true with 0 warnings.