Status: a work queue, not a parking lot. v1 of the PostgreSQL-target analysis engine landed on 2026-09-19 (#3542 closed with the exit check's evidence — nine lanes, twelve PRs incl. #3690). This issue holds the plan's v2 / v3 slices and the residue the v1 lanes reported at path:line. Nothing here waits on a ruling except the two marked maintainer decision; everything else is a lane. The validated plan (V1-BUILD-PLAN.md) and the design doc are on the design bus; the lane protocol that built v1 (one family per lane, file-disjoint partials, threshold_lineage on every bar, D1–D10) carries forward unchanged.

First: the calibration pass (unblocks honest bars everywhere)

• Every PostgreSQL bar shipped tonight is threshold_lineage = 0 (unmeasured). → measured 2026-09-19 10:24Z over 50 Aurora PostgreSQL clusters (comment below); the lineage-flip lane and the Aurora-suppression lane follow from it. The first v2 read is the fleet-distribution pass the SQL Server side got in The scorer's wait thresholds carry their measurement: WRITELOG stops saturating on a third of routine windows, deadlocks grade 5/hr apart from 90/hr, and the absolute gates scale with the hours actually observed (#3538 A5/A7) #3616: per-server distributions over the dogfood PostgreSQL targets for top-1 statement share (pg_statement_stats), temp bytes/sec and TPS (pg_database_stats), peak sessions / ceiling (pg_session_states), wait fraction per type (pg_wait_stats, Aurora), checkpoint requested/timed ratio (pg_write_stats), autovacuum backlog ratio (pg_autovacuum). Then re-derive each bar the V120 way (WARNING near the top of the routine mode, CRITICAL inside a measured empty interval) and flip the lineage comments to measured. Announce-before-firing on the fleet-watch seat; sanitized results on this issue.

v2 slices (from the plan §6)

• IO latency facts + anomaly (PostgreSQL I/O family: an operator now learns how slow each data-file read was, on measured Aurora-storage bars, and hears why when the pass cannot know — timing off or a pre-16 major (partial #3691) #3726) (trackedness-aware: track_io_timing off → unavailable, never 0.000 ms — the MCP payload-contract campaign: the agent-facing API tells the truth (~30 defects + an 11-rule contract) #3541 A8 lesson on get_pg_io_stats).
• Replication lag + slot retention stories (§3.5) (Replication lag and slot retention stories for the PostgreSQL-target engine: a standby's stage and drift, a slot's disk-fill and horizon, on the alert's own bars (partial #3691) #3727) — constants shared with the alert evaluator (D9).
• PG_BLOAT_TREND (§3.4) (PG_BLOAT_TREND: a PostgreSQL operator learns which table is actually accumulating space over fourteen days — growth of the estimate behind a size floor, never the spot percentage that reads 86% on a 2 MB table (partial #3691) #3722) off pg_table_bloat / pg_index_bloat estimates (a NULL est_bloat_pct is "suppressed", never zero).
• PG_IDLE_IN_TRANSACTION (§3.10) (PostgreSQL sessions family: an operator now learns which application left a transaction open and walked away — PG_IDLE_IN_TRANSACTION on measured duration bars, a band higher when it pins the xmin horizon, joined to the saturation story only when parked sessions fill the pool (partial #3691, lane 14) #3733) — the xmin holder kind lane 4 names; the saturation ↔ idle-in-transaction edge lane 3 left as a commented hook.
• Active-query facts; blocking facts + BlockingChainReconstructor port (PostgreSQL blocking family: an operator now learns who headed a blocking chain, in what state, and how long the sessions behind it had really waited — PG_BLOCKING_CHAIN from the sampled edges, PG_LOCK_WAIT_EVENTS from the engine's own log lines, PG_LONG_RUNNING_QUERY from the active sessions, and a blocked-sessions anomaly whose baseline counts a quiet capture as zero (partial #3691, lane 17) #3750) — PG blocking is SAMPLED sightings; Ingest target PostgreSQL logs as telemetry — errors, spills, autovacuum runs, and connection churn are invisible between counter samples #3601's lock_wait log events are the event-grain source (also the Brains-review campaign: deferred structural residue (from #3538 / #3539 / #3540 / #3541) #3653 PG blocking-band item).
• Deadlock exemplar drill-down (PostgreSQL deadlock cards carry the captured exemplars, grouped by shape and ranked by recurrence, so an operator learns the access pattern and not just the count (#3691) #3721) (pg_deadlocks graphs) beside the counter-derived PG_DEADLOCK_RATE (which already says how many the log captured vs the engine counted).
• PG_WAL_VOLUME_SHIFT (§3.11) (The write family tells Aurora the truth: checkpoint pressure and max_wal_size are not applicable where storage owns checkpointing, and WAL volume is graded against its own baseline where the engine reports it (partial #3691) #3728) — the key exists and the .Write.cs edge into checkpoint pressure is declared; the fact is not emitted.
• (A PostgreSQL operator now learns which database is growing, how fast, and when it doubles: PG_DATABASE_GROWTH trends pg_database_size_stats over fourteen days, never a spot size, counts the databases the role cannot size instead of reading them as zero, and the instance's growth rate gets its own anomaly — every bar unmeasured and saying so (partial #3691) #3831 — PG_DATABASE_GROWTH + ANOMALY_PG_DATABASE_GROWTH over pg_database_size_stats, trend never spot, all bars unmeasured) Object growth; contention anomalies DONE as ANOMALY_PG_BLOCKING (PostgreSQL blocking family: an operator now learns who headed a blocking chain, in what state, and how long the sessions behind it had really waited — PG_BLOCKING_CHAIN from the sampled edges, PG_LOCK_WAIT_EVENTS from the engine's own log lines, PG_LONG_RUNNING_QUERY from the active sessions, and a blocked-sessions anomaly whose baseline counts a quiet capture as zero (partial #3691, lane 17) #3750). PG_MAINTENANCE_SHAPE_SHIFT (§3.2) → v3: measured autovacuum worker concurrency is 0–1 on every cluster, ≥ 3 never (calibration B6) — no signal to baseline on this fleet.
• (PostgreSQL targets learn whether the memory configuration fits the host: the §4b worst-case sum against the window's smallest memory_total_bytes roots an advisory at 0.4 and reaches the incident line only when host-memory pressure or temp spills co-fire, the host's sustained reclaimable share is graded, and a stock target reads unavailable (partial #3691, lane 32) #3809 — CONFIG_PG_MEMORY_OVERCOMMIT + PG_HOST_MEMORY_PRESSURE; max_wal_size vs disk stays out: disk free not collected) Composition checks (§4b): shared_buffers + max_connections × work_mem vs host RAM; max_wal_size vs disk — blocked on the host-RAM collector below.
• Offered-vs-delivered co-fire — re-expressed as the anomaly pair (session spike fired, TPS anomaly not) on the calibration's evidence; the raw TPS trend was noise (§A1) (PostgreSQL sessions family: an operator now learns when a pool near its ceiling is accepting more connections than this hour usually carries while completing no more work — the offered-vs-delivered co-fire reads the anomaly pair, and the raw TPS-trend hook is retired on the calibration's evidence (partial #3691, lane 18) #3747) — lane 3's commented hook in PgTargetScorer.Sessions.cs reads Metadata["trend"]; lane 6 shipped PgTargetScorer.TpsTrendKey = "tps_trend" — rename + uncomment (two lines) once the TPS trend is judged stable.

v3 slices (from the plan §6)

• Viewer / worker surface for collection_caveats (today only the MCP payloads and one Warning log line carry them — A pass whose fact families could not be read says so: analyze_server and get_analysis_facts carry collection_caveats on both SKUs, so a blind pass stops reading as an all-clear (partial #3691) #3763). — SPLIT 2026-09-22: the WORKER surface is DONE — A scheduled analysis pass's failed family reads are now readable on get_collection_health instead of dying in a log line (#3691) #3881 (lane 45: a process-wide CollectionCaveatLedger every analysis pass writes, scheduled or not; get_collection_health on both SKUs carries analysis_caveats with per-family persistence when a recent pass could not read a family; the analyze_now result says the same); the VIEWER surface is WAITING-ON a Windows build seat — the Viewer is WPF, the coordinator's Mac cannot build or execute it, and CI would be its first execution; brief on request if CI-first verification is acceptable. — DONE 2026-09-24: the Viewer surface shipped in Persist analysis collection caveats in a store table (V141, #3691 part a1) #4154 (rung V141, collect.analysis_collection_caveats) and 3691 part a2 — Viewer shows persisted analysis collection caveats #4155 (a section on the SQL Server Collection Health tab and the PostgreSQL Overview tab, rendered on a Windows VM; comment 5813059565).

• A string seam on Fact (or a DrillDown) so top-N cards can name more than their worst object (Fact.Metadata is doubles-only — A PostgreSQL table that turned autovacuum off and fell behind is its own card: CONFIG_PG_AUTOVACUUM_DISABLED names the table, how far past its own trigger line it sits and for how long, and joins the backlog's story on the same table (#3691 step 22) #3761, PG_BLOAT_TREND: a PostgreSQL operator learns which table is actually accumulating space over fourteen days — growth of the estimate behind a size floor, never the spot percentage that reads 86% on a 2 MB table (partial #3691) #3722, The vacuum family of a PostgreSQL analysis pass: a table persistently past its own autovacuum trigger line is named with its ratio, slope and whether autovacuum ran and lost, the wraparound counter and the xmin holder grade on the very constants the Tier-0 alerts page on, and the three chain into one story (#3542 lane 4) #3674 all hit it). — A summary card names the objects it ranked instead of counting them: three PostgreSQL cards stop hiding table names in metadata keys (#3691) #3864 (lane 43; typed Fact.Ranked list capped at 3, [0] pinned to the fact's own object; ranked on both engines' analyze_server root_fact and get_analysis_facts cards only when ≥ 2 ride; the autovacuum-disabled rank keys, the bloat growth_*_<name> prefixes and the one-row backlog card retired; SQL Server and every non-ranking card byte-identical, pinned)

• The greedy single-path walk orphans config leaves not reachable from the path's tail (CONFIG_PG_MAINT_WORK_MEM roots alone at 0.6 beside a backlog → wraparound → hold chain) — engine item, both engines. — A configuration lever hanging off a diagnostic chain is attached to that finding instead of orphaned into a card of its own, so a vacuum backlog and the memory bound that caps how fast it can clear arrive as one story (#3691) #3850 (lane 42; AnalysisStory.SideLeafKeys / side_leaves on both engines, classified by SOURCE because CONFIG_PG_MAINT_WORK_MEM is evidence-gated and not an advisory root; path/hash untouched; SQL Server structurally cannot produce one — pinned)

• (A PostgreSQL operator now learns which statement got slower when its plan changed, and why: PG_PLAN_REGRESSION joins the captured plan_hash flip to the statement's per-call step, PG_PARAMETER_SENSITIVITY names the skewed predicate column behind a multi-plan statement, and the server-wide per-call mean is baselined (partial #3691, lane 27) #3798) Plan regression (statement step-change × plan_hash flip via pg_statement_stats + captured plans); parameter sensitivity (plan_hash variance × top_value_frequency skew).

• (A PostgreSQL operator now learns which large relation a statement reads sequentially under a selective predicate, how often, and what an index would cost — PG_SEQ_SCAN_ADVISORY from plan_json Seq Scan nodes beside pg_qualstats selectivity and pg_table_bloat_stats size, evidence first (partial #3691, lane 30) #3811 — the PostgreSQL card, built under the refined discipline) Index-candidate analysis — RULED 2026-09-20 (refined): the analysis starts from the measured-slow query; a candidate/request is corroboration, never the driver; impact labelled "one operator's estimated cost" (never a % or a promise), uses labelled plan-cache-bounded, sample counts labelled sampled; every suggestion card states that a new index can cause regressions elsewhere and must be tested; advisory band; never a defining characteristic of the engine. Applies to BOTH SKUs. Lane 30 builds the PostgreSQL card under it. pg_qualstats / plan-JSON candidates surface as predicate, evaluation count, sample rate, selectivity, estimate error; no CREATE INDEX text anywhere (the standing no-missing-index-folklore rule).

• plan_json Seq-Scan advisories (A PostgreSQL operator now learns which large relation a statement reads sequentially under a selective predicate, how often, and what an index would cost — PG_SEQ_SCAN_ADVISORY from plan_json Seq Scan nodes beside pg_qualstats selectivity and pg_table_bloat_stats size, evidence first (partial #3691, lane 30) #3811, evidence-first with the regression caveat pinned); kernel-stats CPU decomposition (waiting vs burning) (A PostgreSQL operator learns how many cores their statements are burning and whether the backends are burning or waiting: pg_stat_kcache cores busy as the self-hosted CPU proxy graded only against the server's own hour-of-week routine, a burning-versus-waiting decomposition that becomes a finding on its own instrument's co-fire, and one honest unavailable fact on the measured fleet where the extension does not exist (#3691 lane 28) #3800); buffer-composition drill-down (pg_buffer_usage) (PostgreSQL buffer-pressure cards carry what the cache HOLDS — the latest pg_buffer_usage capture as pool fill, the ten largest resident relations, the index/heap/TOAST split and the cold share, folded into the advice, so an operator learns whether shared_buffers is one relation or a working set (#3691) #3795 + The buffer-composition drill-down's pressure block carries the fact's counts and observed span rather than a second copy of its per-second quotients, and its rounding helper reads whole — the two censuses #3795's pre-CI merge reddened on dev (#3691) #3799 + The member scan's known-truncated roster names the buffer drill-down's nullable rounder (#3691 lane 29 residue; dev red since #3795) #3804); Aurora peakmem per-query metadata; extension/meta advisories beyond the v1 pair; self-hosted CPU proxy. — remainder WAITING-ON measurement (2026-09-22): Aurora peakmem per-query needs aurora_stat_* columns whose presence on the fleet is unmeasured (a D-batch read first); extension/meta advisories beyond the v1 pair have no failure population behind them (the two v1 checks came from measured gaps); the self-hosted CPU proxy has population 0 (pg_stat_kcache absent fleet-wide, batch C §C6/D6). None is idle-by-choice: each is a bar with no evidence to set it against yet.

Collector follow-ups feeding later slices (each trips ReadmeDerivedCountPinTests by design)

• (PostgreSQL targets get a per-database size series (pg_database_size_stats, hourly, a year) and the host's memory as six byte columns on pg_cpu_utilization's Performance Insights row (Darling V136), so the object-growth and memory-composition lanes have a source (partial #3691) #3794, V136 — six memory columns on pg_cpu_utilization from Performance Insights; stock: no row) Host RAM for PostgreSQL targets — the composition checks' blocker and the cross-server-transfer blocker the review named.
• Disk free space; per-database size series (PostgreSQL targets get a per-database size series (pg_database_size_stats, hourly, a year) and the host's memory as six byte columns on pg_cpu_utilization's Performance Insights row (Darling V136), so the object-growth and memory-composition lanes have a source (partial #3691) #3794, pg_database_size_stats, hourly, 400 d); per-database settings. — lane 46 (2026-09-22): per-database settings (pg_db_role_setting) as a snapshot beside pg_server_config; disk free space STRUCK 2026-09-22: no in-engine SQL source on either engine (stock PostgreSQL has no free-bytes function — pg_database_size/pg_tablespace_size are USED bytes, already collected; Aurora exposes FreeLocalStorage only through CloudWatch, and the collectors speak SQL only); the store host's own disk is already watched by the service's disk-pressure self-alert. Per-database settings DONE — A pg_server_config row now says whose setting it is, so a database that overrides work_mem stops being invisible (#3691) #3882 (lane 46; rung V138: database_name/role_name on pg_server_config, the collector UNIONs pg_db_role_setting, all ten server-wide reads exclude the overrides and one selects them — pinned by anchor — and get_pg_server_config publishes database_overrides).
• numbackends on pg_database_stats (pg_database_stats stores numbackends and pg_wait_sampling stores sampled_ms (Darling V133), so a PostgreSQL operator's saturation fraction has a numerator and the sampler arm's wait rate has its duty-cycle denominator (partial #3691) #3716, V133 — stored; consumer switch PostgreSQL sessions family: an operator's connection-saturation card now divides pg_stat_database.numbackends — the universal one-minute level, summed over databases at one instant, peaked over the window — by the ceiling, and names the exception-capture peak as its stated fallback; both readings ride the fact, the bars do not move (partial #3691, lane 25) #3782 — the saturation numerator is numbackends, capture peak as the stated fallback) — a RUNG (universal 1-min client-only numerator for saturation instead of exception-capture peaks). Ladder-sequenced with the other seat.

Residue the v1 lanes reported (path:line; each S unless marked)

• Lineage flip, round 3 (calibration D): ANOMALY_PG_BAD_ACTOR_SHARE's reuse of PgRatioAnomalyThreshold 3.0 → measured for statement share (≈ p99.1 of per-statement hour-of-week ratios, p99.6 with the busy/share floor; window fenced at 2026-09-19 16:40Z, before the .453 regression); the keyed per-queryid mean-ms ratio → measured (3.0 ≈ p99.3). Memory / growth bars stay unmeasured until V136 is installed on the fleet (D1/D2/D4 re-fire then). S. — ANOMALY_PG_PLAN_REGRESSION reads each flipped statement's OWN hour-of-week per-call mean; the server-wide mean is the cold fallback — the third calibration read's lineage lands (partial #3691) #3845 (lane 39; server-wide mean kept as the cold fallback, series stamp 1/0; no bar value changed)

• Switch ANOMALY_PG_PLAN_REGRESSION to the keyed per-queryid mean-ms series (lane 27's follow-up, now EVIDENCED by D5: the server-wide mean's hour-of-week ratio never reaches 3.0 across 50 clusters in a week (max 4.4, p99 2.05 — a 90× per-statement step dilutes to nothing), the keyed series has a real tail (p99.9 57×)). The seam exists (A baseline series can now be scoped to ONE statement: the per-key seam on PgBaselineProvider (a keyed GetBaselineAsync overload, a third resolve seam, $7 after the Q6 clock) and two per-queryid arms — a statement's share of the collection's execution time and its per-call mean — so a PostgreSQL bad actor can be judged against its OWN hour-of-week habit; no consumer yet (partial #3691, lane 33) #3810); the detector partial PgTargetAnomalyDetector.Plans.cs reads the keyed arm for each candidate statement and folds onto PG_PLAN_REGRESSION for the SAME queryid. S/M. — ANOMALY_PG_PLAN_REGRESSION reads each flipped statement's OWN hour-of-week per-call mean; the server-wide mean is the cold fallback — the third calibration read's lineage lands (partial #3691) #3845 (lane 39; server-wide mean kept as the cold fallback, series stamp 1/0; no bar value changed)

• (The PostgreSQL engine absorbs what waves 4–5 reported back: get_pg_database_stats surfaces numbackends, get_pg_cpu_utilization carries the host's memory, the spill leads to the memory composition check, ANOMALY_PG_CPU_BURN is the load family's stock second confirmer, autovacuum_enabled = off reads as off, the replication e2e is anchored, and four stale docs say what is true now (partial #3691, between waves) #3832 item 8 — NOT option_value::boolean, all seven spellings verified live) BUG PgAutovacuumStatsCollector.cs:143/:161 lower(option_value) = 'false' — PostgreSQL stores reloptions as typed (off/0/no/f), so autovacuum_disabled never reads true and CONFIG_PG_AUTOVACUUM_DISABLED cannot fire (lane 36, verified live) → lane 37 item 8.

• PG_XMIN_HOLD reads 0 when several equally-old transactions alternate as is_winner — the identity arm sees each win once (PgTargetFactCollector.Vacuum.cs:~220-247; lane 36 saw a 4.3 M-xid horizon score 0). Design: count the HORIZON's persistence, attribute the winner separately. M. — PG_XMIN_HOLD measures the HORIZON's persistence and attributes the holder separately — five equally old transactions taking turns no longer score 0 on a horizon they held for 25 minutes (partial #3691) #3844 (lane 40; the horizon's persistence is graded on the longest run above the bar across captures, attribution is a separate arm)

• An all-zero baseline history yields EffectiveStdDev = 0 → the absolute fallback (BaselineBucket.cs:~98): ANOMALY_PG_BLOCKING sat at 0.5 with 92 blocked sessions against a clean month. A zero-history bucket should be the STRONGEST evidence, not none — shared engine, both SKUs. M. — A month of zeros is the strongest baseline there is, not the absence of one: a zero-history bucket now fires as an extremity instead of routing to the young-store fallback bar (#3691) #3849 (lane 41; BaselineBucket.IsZeroHistory + the extremity arm at the top of AnomalyGate.Decide, both SKUs; 23 pre-existing calibration pins untouched; the planted SQL Server store has no such bucket so its output is unchanged)

• D8 — acceptance read for the zero-history arm (A month of zeros is the strongest baseline there is, not the absence of one: a zero-history bucket now fires as an extremity instead of routing to the young-store fallback bar (#3691) #3849) on the keyed share series: count ANOMALY_PG_BAD_ACTOR_SHARE fires carrying baseline_zero_history = 1 and their share values in the first week of .458 (D3B measured 21% of top-5-statement hour-of-week cells as zero-history). If the rate is dominated by appearances just over the 0.05 share floor, raise that family's zero-history magnitude floor to a measured bar. WAITING-ON install + one week: fire ≥ 2026-09-29 03:30Z (pgmon, analysis_findings/facts read, announce first). — DONE 2026-09-24: 71 of 1,990 share findings were zero-history (3.6 %, 16 clusters), median window share 8.6 %; at most 34 % could be near the floor, so the floor is unchanged (comment above).

• (The PostgreSQL engine absorbs what waves 4–5 reported back: get_pg_database_stats surfaces numbackends, get_pg_cpu_utilization carries the host's memory, the spill leads to the memory composition check, ANOMALY_PG_CPU_BURN is the load family's stock second confirmer, autovacuum_enabled = off reads as off, the replication e2e is anchored, and four stale docs say what is true now (partial #3691, between waves) #3832 items 2+3) PgTargetToolRecommendations names get_pg_cpu_utilization for the memory keys but that tool does not project the six memory columns (PostgreSQL targets get a per-database size series (pg_database_size_stats, hourly, a year) and the host's memory as six byte columns on pg_cpu_utilization's Performance Insights row (Darling V136), so the object-growth and memory-composition lanes have a source (partial #3691) #3794's positive census names the collector as the only reader) — extend DarlingPgCpuUtilizationReader (+ census) or re-point the row at get_analysis_facts source=pg_memory; and PG_TEMP_SPILL → CONFIG_PG_MEMORY_OVERCOMMIT edge from PgTargetRelationshipGraph.Query.cs (source-owns-edges; the amplifier already lifts). S, next shared batch (PostgreSQL targets learn whether the memory configuration fits the host: the §4b worst-case sum against the window's smallest memory_total_bytes roots an advisory at 0.4 and reaches the incident line only when host-memory pressure or temp spills co-fire, the host's sustained reclaimable share is graded, and a stock target reads unavailable (partial #3691, lane 32) #3809).

• (The PostgreSQL engine absorbs what waves 4–5 reported back: get_pg_database_stats surfaces numbackends, get_pg_cpu_utilization carries the host's memory, the spill leads to the memory composition check, ANOMALY_PG_CPU_BURN is the load family's stock second confirmer, autovacuum_enabled = off reads as off, the replication e2e is anchored, and four stale docs say what is true now (partial #3691, between waves) #3832 item 7 — ANOMALY_PG_CPU_BURN is a load-family confirmer; lane 36's measured gap closed) Wire the stock second confirmer (A PostgreSQL operator learns how many cores their statements are burning and whether the backends are burning or waiting: pg_stat_kcache cores busy as the self-hosted CPU proxy graded only against the server's own hour-of-week routine, a burning-versus-waiting decomposition that becomes a finding on its own instrument's co-fire, and one honest unavailable fact on the measured fleet where the extension does not exist (#3691 lane 28) #3800 out-of-lane): PgTargetScorer.Anomaly.cs LoadAnomalyAmplifiers — ANOMALY_PG_CPU_BURN fired joins the load-family confirmers and AnomalyAmplifiers(AnomalyCpuBurn) gets the load arms (today the burn anomaly is a solo card under the 1.49 cap); AnomalyToFamilies[AnomalyCpuBurn] folds onto base-0 PG_CPU_BURN_CORES (unreachable) — consider CpuDecomposition as the family. Gate on lane 36's measurement. S, shared file.

• (The PostgreSQL engine absorbs what waves 4–5 reported back: get_pg_database_stats surfaces numbackends, get_pg_cpu_utilization carries the host's memory, the spill leads to the memory composition check, ANOMALY_PG_CPU_BURN is the load family's stock second confirmer, autovacuum_enabled = off reads as off, the replication e2e is anchored, and four stale docs say what is true now (partial #3691, between waves) #3832 item 1) get_pg_database_stats (DarlingPgDatabaseReader.cs:~20) does not surface numbackends — a level-only saturation card has no tool that shows the count behind it; add the column to that read (+ README :572 / runbook sentence from pg_database_stats stores numbackends and pg_wait_sampling stores sampled_ms (Darling V133), so a PostgreSQL operator's saturation fraction has a numerator and the sampler arm's wait rate has its duty-cycle denominator (partial #3691) #3716). S.

• (The PostgreSQL engine absorbs what waves 4–5 reported back: get_pg_database_stats surfaces numbackends, get_pg_cpu_utilization carries the host's memory, the spill leads to the memory composition check, ANOMALY_PG_CPU_BURN is the load family's stock second confirmer, autovacuum_enabled = off reads as off, the replication e2e is anchored, and four stale docs say what is true now (partial #3691, between waves) #3832 item 5 — every planted timestamp anchored on the test's as_of) PgTargetReplicationTests.ADriftingStandbyAndAnInactiveGrowingSlot… is a live FLAKE (red on two PR runs — lanes 24 and 26 — green on dev's re-run each time): timing assumption in the fixture; pin it deterministic. S.

• (PostgreSQL sessions: a window with no session capture still grades connection saturation from pg_stat_database.numbackends as a level-only card that says its states are unobserved, and the Aurora wait-profile advice names the window mean against its routine (partial #3691, lane 26) #3791 — level-only card; the redacted-majority-WITH-captures half remains a ruling) A window with NO session capture still emits no saturation fact although numbackends can now supply the numerator alone — the level-only card is the next honest step (PostgreSQL sessions family: an operator's connection-saturation card now divides pg_stat_database.numbackends — the universal one-minute level, summed over databases at one instant, peaked over the window — by the ceiling, and names the exception-capture peak as its stated fallback; both readings ride the fact, the bars do not move (partial #3691, lane 25) #3782 out-of-lane); under a redacted-majority window the ratio is still withheld though pg_stat_database is unprivileged — ruling. S.

• (A baseline series can now be scoped to ONE statement: the per-key seam on PgBaselineProvider (a keyed GetBaselineAsync overload, a third resolve seam, $7 after the Q6 clock) and two per-queryid arms — a statement's share of the collection's execution time and its per-call mean — so a PostgreSQL bad actor can be judged against its OWN hour-of-week habit; no consumer yet (partial #3691, lane 33) #3810 seam + A PostgreSQL bad actor is now graded against its OWN normal: ANOMALY_PG_BAD_ACTOR_SHARE judges each top statement's window share against that statement's hour-of-week share bucket and walks into its PG_BAD_ACTOR card, which becomes a context band under the story line with the absolute share bars as named measured-routine context, so a statement at its usual 60% is the workload and a statement at 55% that usually takes 10% is the story (partial #3691, lane 34) #3827 re-grade: ANOMALY_PG_BAD_ACTOR_SHARE against the statement's own hour-of-week share, absolute share as context) RULED 2026-09-20 → lanes 33 (per-key baseline seam) + 34: re-grade the bad-actor share as deviation from the statement's OWN hour-of-week share baseline, absolute share as context (derive-not-constant; the percentile raise rejected). (was: bad-actor share bars 0.25 / 0.60 are ROUTINE given the busy floor (85 % / 44 % of busy hours on 24 clusters) — raise to ≈ p90 / p99 of busy hours (0.85 / 0.90), or re-grade as deviation from the statement's own hour-of-week share baseline with the absolute share as context. Maintainer decision; then a lane.

• (PostgreSQL wait standouts, the I/O admission floor and the ratio multiple say what the second fleet read found: measured per family, cited 2026-09-20, and every Aurora wait fact stops calling a validated bar a guess (#3691 lineage flip, round 2) #3785) Lineage flip, round 2 (calibration C): PgRatioAnomalyThreshold 3.0 → measured for TPS (≈ p99.97) with the per-family note that for waits the ratio alone is routine (p93) and the magnitude floor (8× fleet p99) is the gate; wait standouts 0.15 / 1.0 → measured (p99.6 / p99.99 of non-IO event buckets); IoBaselineBucketMinimumReads 250 → measured (57 % of fleet 15-min buckets excluded; hour-of-day tier for half the fleet stated); sessions bars keep the numbackends note (lane 25); sampled-wait bars stay unmeasured (population 0). S.

• (PostgreSQL sessions: a window with no session capture still grades connection saturation from pg_stat_database.numbackends as a level-only card that says its states are unobserved, and the Aurora wait-profile advice names the window mean against its routine (partial #3691, lane 26) #3791) PgTargetAdvice.Anomaly.cs ComposeWaitProfileRatio (~:258) does not name the window mean the Aurora fact now carries (mean_ms_per_sec / mean_modified_z); the sampled composer (PgTargetAdvice.Wait.cs:~205) does — The wait-profile detector judged the window peak alone: its inline gate becomes the shared AnomalyGate pair call every other baseline detector took in #3724, so one hot collection in a quiet window stops reading as a profile shift (#3741) #3773's advice enrichment has no PG-target twin. S.

• (Stock PostgreSQL's sampled wait profile fires its first-occurrence reading on the peak's bar alone, like its Aurora and SQL Server twins — a young server's one hot sampler cycle is no longer held by a mean it has no baseline to judge (partial #3691, lane 35, ruled 2026-09-20) #3808) RULED 2026-09-20 → lane 35: the sampled twin matches the unsampled twin's is_new gating (peak-only), lineage marked unmeasured, revisit if a pg_wait_sampling cluster ever exists. (was: the sampled twin (PgTargetAnomalyDetector.WaitsSampled.cs:~204) pair-gates its is_new arm; The wait-profile detector still fires on the window peak alone: its inline gate has no mean, unlike every detector #3724 pair-gated (Q1 residue) #3741/The wait-profile detector judged the window peak alone: its inline gate becomes the shared AnomalyGate pair call every other baseline detector took in #3724, so one hot collection in a quiet window stops reading as a profile shift (#3741) #3773 ruled peak-only for the SQL Server and Aurora arms — pick one for the PG family. Maintainer decision.

• Aurora wait-profile detector lacks the peak-AND-mean gate (The PostgreSQL Long-Running Query read applied excludedDatabases AFTER LIMIT, so an excluded database's sessions consumed the page and the alert came back short or empty while matches existed; the list is now the candidates CTE's third flag ahead of the cap, counted on the card (Closes #3742) — and the Aurora wait-profile detector gains the peak-AND-mean gate its twins have (partial #3691) #3780) its sampled twin has (The anomaly gate judges the window peak AND the window mean, so one hot sample stops reading as an anomaly and a longer window stops buying more of them; I/O reads the pair like its siblings (Partial #3653 — item 1, Q1) #3724's gate; lane 9 root body PgTargetAnomalyDetector.cs) — parity item, one arm. S.

• PostgreSQL-target buckets stay UTC-keyed after Q6 (Hour-of-week baselines key on the target's local clock, not UTC: one shared step-function expression re-keys every arm through the scaffold, three bound clock parameters from server_properties (zone id, offset fallback, UTC when there is no row), the lookup through the same numbers — nothing keyed is stored, so re-bucketing is the next compute (#3653 item 12, Q6) #3749) (PostgreSQL targets key their hour-of-week buckets on their own TimeZone setting, so a New York target's Tue 09:00 bucket is 09:00 in New York in every season — the clock read becomes the provider's second seam, UTC becomes the fallback instead of the rule (partial #3691, lane 20) #3757): the local-clock re-keying reads server_properties for the zone, and PostgreSQL targets have no such row — a PG-target clock source is needed (pg_settings.TimeZone from pg_server_config is the likely one; the collector reads it already) feeding BaselineLocalClock for PgTargetBaselineProvider. Until then every PG hour-of-week baseline is UTC hour-of-week (stated, not hidden). M.

• PgTargetBaselineProvider.cs root doc says the base binds only $2/$3 (PostgreSQL targets key their hour-of-week buckets on their own TimeZone setting, so a New York target's Tue 09:00 bucket is 09:00 in New York in every season — the clock read becomes the provider's second seam, UTC becomes the fallback instead of the rule (partial #3691, lane 20) #3757, incl. the TpsTrendKey prose) — since Hour-of-week baselines key on the target's local clock, not UTC: one shared step-function expression re-keys every arm through the scaffold, three bound clock parameters from server_properties (zone id, offset fallback, UTC when there is no row), the lookup through the same numbers — nothing keyed is stored, so re-bucketing is the next compute (#3653 item 12, Q6) #3749 the shared bind path also supplies $4..$6 (transition instant + offsets); one paragraph. S — next shared-file batch, with lane 18's falsified TpsTrendKey prose (PgTargetScorer.Database.cs:50–51, PgTargetFactCollector.Database.cs:23–24, 129–131, 261–265).

• compare_analysis bands the v2 baselined metrics absolutely (compare_analysis sigma-bands the v2 PostgreSQL baselined metrics — I/O read latency, replay lag, WAL volume — so a 16× latency move stops reading by the ladder alone; the write family has one definition of "WAL tracked" (partial #3691) #3748) (v2 exit check): ComparisonBanding.BaselinedMetricFor maps the v1 four only; PG_IO_READ_LATENCY_MS, PG_REPLICATION_LAG, PG_WAL_VOLUME_SHIFT come back band_source: absolute while their detectors say 25σ. + one predicate for "WAL tracked" in PgTargetFactCollector.Write.cs. (lane 19)

• A CRITICAL leaf consumed mid-chain is never NAMED by the root (The root card names the leaves it consumed: a story's root advice now says who was behind the chain — the parked application, the lead blocker, the job — so a CRITICAL leaf walked under a higher root is no longer nameless (both engines, partial #3691) #3759 — story text on both engines; a typed named_hops payload array is a follow-up if wanted: ephemeral list on AnalysisFinding + the two story→finding maps) (v2 exit check, both engines): PG_IDLE_IN_TRANSACTION 1.2 naming its holder sits under PG_CONNECTION_SATURATION 1.25; the root's advice and co_fired never carry the holder's identity — an operator reading only the card cannot find the application. InferenceEngine.BuildStories / story advice composition: the root's advice should carry named leaves' identifiers. Design pass (M, shared, both SKUs).

• Aurora-suppress PG_CHECKPOINT_PRESSURE and CONFIG_PG_MAX_WAL_SIZE (The write family tells Aurora the truth: checkpoint pressure and max_wal_size are not applicable where storage owns checkpointing, and WAL volume is graded against its own baseline where the engine reports it (partial #3691) #3728) (calibration A4): Aurora reports requested-share 0 with 60 synthetic timed "checkpoints" per hour on every cluster and does not populate pg_stat_wal; on aurora-postgres the fact is a permanent measured 0 that means nothing and the convention check is noise. Emit not_applicable with the reason in metadata; the checkpoint → max_wal_size story must not form there.

• Lineage flip to measured (PostgreSQL bars the fleet measured now say so: lineage comments cite the 2026-09-19 read and threshold_lineage flips to 1, so a validated bar stops calling itself a guess (#3691 lineage flip) #3723) (calibration A/B): TPS floor 50 / fallback 500, temp 1 / 10 MiB/s, backlog 3 / 10 / 5, deadlock 5 / 20, bad-actor busy floor 0.05 (+ share bars conditional on it), wait 0.20 / 1.0 / io 0.40 / 2.0, CPU 80 / 95 — comments cite the date and population, threshold_lineage 0 → 1 on those facts; sessions 0.8 / 0.9 stay engine-defined with the measured note (fleet max 10.3 % of ceiling).

• compare_analysis bands a 6× TPS move "stable" (compare_analysis sigma-bands the PostgreSQL baselined metrics, so a 6× TPS surge on a PostgreSQL target stops reading "stable" (#3691 W1/W2) #3713) (exit check W1) — ComparisonBanding.BaselinedMetricFor (ComparisonBanding.cs:~159-166) maps only CPU_SQL_PERCENT / CPU_SPIKE / IO_READ_LATENCY_MS / SESSION_STATS; lane 9's MetricNames.PgTps (same unit, same difference) is unmapped and PG_TPS base severity is 0 so the absolute ladder can never move it; the same window's detector calls it 25σ. Map PG_TPS → PgTps, PG_CONNECTION_SATURATION → PgSessionCount, PG_DEADLOCK_RATE → PgDeadlockRate, PG_CPU_PERCENT → PgCpu. Also plan_cache_churn.note prose says BAD_ACTOR_<hash> in a PG payload (W2, harmless).

• ANOMALY_PG_WAIT_PROFILE stays solo and can never escape the cap (v2 plumbing for the PostgreSQL-target engine: the I/O, replication and bloat families exist as stubs, and the wait-profile anomaly folds onto its wait and can page (partial #3691) #3715) — AnomalyIncidentReconciler.ResolveFamilies resolves the dominant contributor only for the literal ANOMALY_WAIT_PROFILE; PgTargetFactKeys.AnomalyToFamilies has no wait entry; FactScorer.IsExtremeAnomaly has no PG wait-profile arm. Shared-file item.

• PG baseline sources are unfloored at purge (PostgreSQL baselines survive a shortened retention, and pg_cpu carries the CPU dispersion floor, so a 7-day PG retention no longer silently switches anomaly detection off (#3691) #3711) — DarlingRetention.BaselineServingRawCollectors floors only cpu_utilization / file_io_stats; pg_database_stats, pg_session_states, pg_wait_stats, pg_cpu_utilization are user-editable and a shortened retention silently starves the PG baselines (PgBaselineProvider times out client-side scanning raw history, and tiered retention will mask it rather than fix it #1757's shape). Defaults ≥ 30 d are pinned; the runtime floor is the missing half.

• BaselineMath.AbsStdDevFloorFor has no arm for MetricNames.PgCpu (PostgreSQL baselines survive a shortened retention, and pg_cpu carries the CPU dispersion floor, so a 7-day PG retention no longer silently switches anomaly detection off (#3691) #3711) (SQL CPU carries 5.0).

• get_analysis_facts never runs the anomaly detector on EITHER engine (get_analysis_facts runs the anomaly detector on both engines, so the facts read stops omitting the detector's ANOMALY_* facts (#3691) #3714) (DarlingAnalysisService.CollectAndScoreFactsAsync = collector + scorer; Lite twin) — anomaly lineage/gate metadata is visible only in findings. Pre-existing; twin edit.

• (rung pg_database_stats stores numbackends and pg_wait_sampling stores sampled_ms (Darling V133), so a PostgreSQL operator's saturation fraction has a numerator and the sampler arm's wait rate has its duty-cycle denominator (partial #3691) #3716 / V133; consumer read + sampled anomaly arm Stock PostgreSQL's sampled waits read per second the sampler was watching (V133 sampled_ms — ten times what the interval arithmetic said on the service sampler), get their own baseline and ANOMALY_PG_SAMPLED_WAIT_PROFILE detector folding onto the dominant sampled wait, and the exact source wins when both wait tables write one window (partial #3691, lane 24) #3765) Stock PostgreSQL's sampled waits get no anomaly baseline (lane 9, by design) and the Service-side wait sampler for stock PostgreSQL — targets without pg_wait_sampling get no wait accumulation at all #3604 service-sampler arm stores profile_period_ms = 1000 but samples 30 s of each 300 s cycle, so Δsamples × period / observed is a ~10× floor on that arm — the instrument token lives in collector_state, outside the analysis FROM/JOIN whitelist. Whitelist collector_state for analysis reads, or store sampled_ms per row (rung). "Both wait sources non-empty" is not detected (read-then-fallback reads one).

• Saturation ↔ Lock-wait mesh in PgTargetRelationshipGraph.Saturation.cs is safe only while saturation has no other leaf — revisited as the leaves landed: idle-in-transaction (PostgreSQL sessions family: an operator now learns which application left a transaction open and walked away — PG_IDLE_IN_TRANSACTION on measured duration bars, a band higher when it pins the xmin horizon, joined to the saturation story only when parked sessions fill the pool (partial #3691, lane 14) #3733, share-gated), Lock → idle (The PostgreSQL engine absorbs what the v2 lanes reported back: the I/O and WAL baseline tables are floored, the I/O baseline restores hour-of-week at a quarter-hour grain, the WAL co-fire reads the anomaly and not a base-0 fact, a Lock wait reaches its idle holder, and the blocking family exists as stubs for lane 17 (partial #3691, between waves) #3737), Lock/idle → blocking chain (PostgreSQL blocking family: an operator now learns who headed a blocking chain, in what state, and how long the sessions behind it had really waited — PG_BLOCKING_CHAIN from the sampled edges, PG_LOCK_WAIT_EVENTS from the engine's own log lines, PG_LONG_RUNNING_QUERY from the active sessions, and a blocked-sessions anomaly whose baseline counts a quiet capture as zero (partial #3691, lane 17) #3750); saturation-alone byte-identity pinned each time.

• Per-table CONFIG_PG_AUTOVACUUM_DISABLED (design §3.1) has no key (A PostgreSQL table that turned autovacuum off and fell behind is its own card: CONFIG_PG_AUTOVACUUM_DISABLED names the table, how far past its own trigger line it sits and for how long, and joins the backlog's story on the same table (#3691 step 22) #3761); v1 folds the reloption into the backlog fact. wal_level / archive_mode posture facts (§4c did not list them).

• audit_config for a PostgreSQL target answers the honest not_collected envelope (plumbing); a CONFIG_PG_* projection into the same tool is a description-contract change — decide. — DECIDED yes (Erik, 2026-09-22) → audit_config answers a PostgreSQL target with its own settings: the CONFIG_PG_* facts projected into the same recommendations shape, engine in place of edition, and the two checkpointing knobs marked not applicable on Aurora (#3691 line 70) #3867 (lane 44; the CONFIG_PG_* facts project into the SQL Server envelope with engine for edition, string current_values with units, no suggested_value, a fourth status not_applicable for Aurora's checkpoint knobs; the description changed once and the three edition-aware doc comments say resource-based)

• PG_MONITORING_PERMISSIONS at 0.5 — RULED 2026-09-20: 0.5 stands (measured blindness outranks the 0.4 advisory band); no code change.

• (A pass whose fact families could not be read says so: analyze_server and get_analysis_facts carry collection_caveats on both SKUs, so a blind pass stops reading as an all-clear (partial #3691) #3763 + The collection-caveat live pin counts missing families, not reads: step 22's second pg_autovacuum_stats read is the same one missing vacuum family (follow-up to #3763, partial #3691) #3767, both SKUs; Viewer surface for the caveats is a v3 candidate) Per-family collector failures are logged, not carried on the context: a pass where every family silently failed reads as a normal pass (both SKUs, pre-existing); empty prose cannot distinguish "facts scored, nothing fired" from "no fact emitted" without a fact-count surface.

• PgSampledWaitProfileFallbackMsPerSec deliberately undeclared (Stock PostgreSQL's sampled waits read per second the sampler was watching (V133 sampled_ms — ten times what the interval arithmetic said on the service sampler), get their own baseline and ANOMALY_PG_SAMPLED_WAIT_PROFILE detector folding onto the dominant sampled wait, and the exact source wins when both wait tables write one window (partial #3691, lane 24) #3765 declared it with its reader) — arrives with the sampled anomaly arm.

• MEASURED 2026-09-20 (comment): NOT a gap in general — four stock stories cross 1.5 (two with zero baseline); the one capped family is the load-anomaly pair, fixed by wiring ANOMALY_PG_CPU_BURN as a confirmer (lane 37 item 7). RULED 2026-09-20 → lane 36 MEASURES it: a stock PostgreSQL in local Docker under a pgbench load storm, the real collectors writing a throwaway store, analyze_server counting reachable families and the max achievable severity — the measurement decides whether the ceiling is a gap. (was: Notification on a STOCK target under a load storm cannot cross 1.5 on anomalies alone (the second confirmer is PG_CPU_PERCENT ≥ 80, Aurora-only) — the self-hosted CPU proxy (v3) is what closes it; until then it is stated, not hidden.

Not here

• Brains-review campaign: deferred structural residue (from #3538 / #3539 / #3540 / #3541) #3653 — the brains-review structural residue (SQL Server side + shared).
• analyze_server for PostgreSQL targets — the inference engine answers 'what is wrong, ranked' for one engine only #3605 — folded into v1 as a design input (its three contributions landed in the plumbing).