The companion-object remedy told 23 clusters to UPDATE an extension none of them had: the pg_extension row now ARRIVES at the fault mapping, and the remedy is the row's rather than an inference's (#3830)

[erikdarlingdata]

pg_statement_stats declares pg_stat_statements_info as a companion the extension gains at 1.9, and since #3818 a 42P01 naming it is recorded as a companion fault with one remedy: ALTER EXTENSION pg_stat_statements UPDATE. That remedy was reached by inference — the base object resolved, therefore the extension is present, therefore it is present below 1.9 — and the middle step does not survive the Aurora flavor, where the base object that resolved is aurora_stat_statements(), which is not the extension's and needs no extension at all. The store-side read of pg_extension_availability settled what the 23 clusters #3818 counted actually were: installed_version empty in every database, the extension never created anywhere, the collector productive throughout through the Aurora function. The sentence told them to update something they did not have.

The row arrives instead of being inferred

PostgresDetectionQueryText — the statement every PostgreSQL connect already runs — gains one scalar: pg_stat_statements' extversion in the connected database, NULL when pg_extension has no row for it. No second query, no extra round trip, no grant beyond what the connect already needs. The extension name is a literal because a const cannot interpolate, and a pin compares it against PgStatementStatsCollector's own RequiredPgExtensions declaration so the two cannot drift.

It lands on ServerRuntime as a PgExtensionRowObservation: the row, plus the database it was read in, plus an Observed flag whose default is not observed rather than no row — a SQL Server target, a hand-built runtime and a host that never ran the read all produce default, and those two readings are opposite remedies. It rides on the runtime rather than on CollectorTargetInfo because nothing dispatches on it, and CollectorTargetInfo is the type whose facts the engine-capability sweep has to vary or fix.

PostgresFaultOutcome takes the observation and the flavor as two optional parameters, scopes the observation to the database the fault came from (pg_extension is per database, and a RunsPerDatabase collector faults in databases the connect-time read never saw), and asks the declared companion for a verdict. The verdict is computed at the mapping from the stored row, never stored itself — the same division CollectorMeasurement states, for the same reason.

Four verdicts, four sentences

• No row, Aurora — nothing for ALTER EXTENSION to update; the collector's source is the declared aurora_stat_statements(), which needs no extension, so it is not waiting on one; CREATE EXTENSION is optional and what it buys is the companion and nothing else.
• No row, vanilla — CREATE EXTENSION, with the shared_preload_libraries sentence back, because the declaration's InstallKind says the module has to be loaded before the create does anything.
• Below 1.9 — pg_statement_stats dead on 23/50 PostgreSQL clusters since .453: the pg_stat_statements_info read fails the whole collector where the extension is below 1.9 or outside public — gate on to_regclass, not the server major; fix the false EXTENSION_MISSING text #3818's remedy, with the version read out of the catalog and named, rather than offered as the first of two possibilities.
• At or above 1.9 — no update is owed and it would change nothing; the object is outside the schema the query names, or the error text says. 1.10 is the case that decides whether the comparison is a comparison: an ordinal string compare ranks 1.10 below 1.9 and would send a fleet two releases ahead back to run an update it has already run twice, which is this defect one version further on.
• Nothing observed, or a version nothing can rank — pg_statement_stats dead on 23/50 PostgreSQL clusters since .453: the pg_stat_statements_info read fails the whole collector where the extension is below 1.9 or outside public — gate on to_regclass, not the server major; fix the false EXTENSION_MISSING text #3818's two-possibilities sentence, byte for byte. extversion is free text the extension's author chooses, so a version that cannot be ranked answers Undetermined rather than guessing a side. This is the hedge, kept only where there is no answer to prefer over it.

What the flavor half rests on

PgExtensionDependency.AuroraNativeAlternative declares what the collector reads on Aurora instead of the extension's base object. Nothing else reads it; its only effect is that an absent extension can be called optional. A collector that reads its extension on Aurora too leaves it null and gets the required-install sentence, and a pin asserts the declared name is a surface the generated Aurora query actually calls and the vanilla query does not.

Corrections carried

Three comments in #3824's file set attributed the 1.8 state to those 23 clusters as fact. They now say which state was measured (pg_extension_availability: no row) and which was assumed. Below-1.9 remains a real state with a real remedy; it was not theirs, and the live rig that proves the gate holds at 1.8 proves it for one of the two absences rather than for the fleet.

Pins

PostgresFaultOutcomeTests asserts each of the four sentences as a whole string, not as fragments: the defect was a sentence whose clauses were individually plausible and wrong together. The fallback is asserted as equal to the no-argument call, so "the hedge is #3824's text" is pinned rather than commented. PgStatementStatsFlavorTests pins the declaration, the verdict over a fake row set (no row, 1.8, 1.9, 1.10, blank, unrankable), the per-database guard, and the version comparison on the pairs a string compare gets wrong. A source pin covers the wiring — read, carried, passed — because a revert that dropped the argument would compile, run, and go back to one remedy for three states with every sentence pin still green.

One pin repaired, not worked around

#2228's tripwire pin asserted EndsWith("connected_database") on both detection queries while its own doc said what it was protecting: the readers index by number, so a column inserted ahead of it shifts five other fields onto the wrong values. "Last in the list" is not that claim — it forbids appending, which cannot shift anything, and it would have passed a column inserted before connected_database with the reader updated to match. It now parses each select list into its trailing aliases and reads the ordinal that method's own body passes to IsDBNull, and compares the two; neither number is written down. A control on an arranged input asserts the parse counts columns rather than commas, since both queries carry a comma inside a function call and a comma inside a comment, in both comment spellings. Verified red-first by inserting a column ahead of connected_database.

No migration rung. No collector query changed. Lite has no PostgreSQL connect path and maps no PostgreSQL fault text, so there is no twin to keep in step.

Closes #3830