Page on a same-statement pileup while it is happening, from the collectors that already saw it (#3467)

[erikdarlingdata]

Page on a plan-flip pileup from the two collectors that were already current while it ran

Closes #3467

A parameterized statement joining a #temp table flipped to a plan doing ~35x the logical reads. Every caller shares the parameterized plan, so ten tenants inherited the flip at once: concurrent executions convoyed on PAGEIOLATCH_SH, physical reads saturated the volume, and sixteen executions hit the client's 30-second command timeout together. The whole episode ran about ninety seconds and self-cleared when the plan churned out.

The collection side was never behind. The 20:10:31Z active-query snapshot held three concurrent copies of the one statement — 29,124 ms / 28,343 ms / 27,703 ms elapsed, 1,351 ms CPU and 287,049 logical reads on the leader, two suspended on page IO — sitting next to that same statement's 20:07:01Z observation at 54 ms. Evidence sufficient to describe the incident existed in the store while the incident was still running, and nothing could page on it:

• the timely findings were the right shape and capped under the gate — ANOMALY_QUERY_DURATION 0.72, ANOMALY_BATCH_REQUESTS 1.0, ANOMALY_CPU_SPIKE 0.56, against notify_severity 1.5;
• the finding that did clear 1.5 (PLAN_REGRESSION, 20:38:49Z) keys off query_store data that had not landed yet;
• no alert family covers the shape: long_running_query triggers at 30 minutes and the victims died at 30 seconds, poison_wait does not class PAGEIOLATCH, blocking/deadlocks do not apply, CPU stayed near 50%.

So the tool watched an outage it could describe and could not report. This adds the finding the issue proposed, computed from the two collectors that were already current.

The finding

SAME_STATEMENT_PILEUP: N concurrent sessions on one statement at one snapshot instant, every copy past a floor of elapsed time, at least one suspended on an IO-class wait, where that same statement's own snapshots across the prior 45 minutes were sub-second. The conjunction is what makes it specific — on the fleet data it fired exactly once in four server-days, and that firing was this incident.

Severity prices magnitude rather than presence (#3462): sessions × min-elapsed-seconds ÷ 40, capped at the band ceiling.

Placement, and the achieved latency

The finding is evaluated on the collection cadence, not the analysis interval — the Darling worker's per-server sweep on the 30-second alert-sweep stamp, Lite's one-minute collection loop, in both cases immediately behind the collectors that write its input.

Achieved latency for the measured incident: inside one collection cycle of the snapshot that proved it. The 20:10:31Z snapshot is read and evaluated on the next sweep stamp (≤30 s on Darling, ≤60 s on Lite), so the finding exists at severity 2.0 against the 1.5 gate — and notifies — by roughly 20:11Z, while the episode that self-cleared around 20:11 was still alive. Against the measured baseline: the scheduled anomalies landed 20:31:48Z (21 minutes, all capped ≤1.0), and the notify-eligible PLAN_REGRESSION could not exist before ~20:38Z (~28 minutes). Detection moves from ~28 minutes after the damage to inside the damage.

It also deliberately does not inherit the scheduled pass's 24-hour data-span gate. That gate exists because fraction-of-period fact scoring distorts on short windows; this finding's evidence is one snapshot plus one statement's own recent history, so it works on a young install.

Alternatives rejected, and why the issue was right to reject them

• Magnitude-scaled severity on the existing anomalies, plus a faster analysis sub-pass. Cheaper, and it is the one alternative that could plausibly have been argued back. It fails on both halves. The severity half is a real improvement that does not solve this: ANOMALY_BATCH_REQUESTS was already at 1.0, so a mass-timeout window would need roughly a 50% scale-up to clear 1.5 — recalibrating a whole-server anomaly family's ceiling on the strength of one incident class, which is what Anomaly findings fire at 0σ against healthy baselines - memory pressure reports "spiked to 100% - 0σ above its 100% baseline" #1996 documents the cost of. The cadence half is the fatal one: a sub-pass fast enough to matter for a 90-second episode is per-collection evaluation, so "anomalies plus a faster sub-pass" converges on this change while carrying the anomaly family's whole-server framing — and a whole-server anomaly cannot name the statement, so it cannot carry the statement-scoped fingerprint the recurrence needs or the force-plan drill-down [ON HOLD] [FEATURE] Auto force plan bot — detect bad Query Store plans (CPU-weighted), force with self-review, evict-first option #2138 wants. The cost argument also does not hold: a per-sweep evaluation here is one index-pruned window read per server (idx_query_snapshots_time on (server_id, collection_time) prunes the range; the projection fetches the ~50–150 rows) and a pure in-memory predicate, on the same cadence the long-running-query alert already reads this table.
• Lowering notify_severity. Rejected in the issue and not revisited: it trades this gap for noise fleet-wide, and Anomaly findings fire at 0σ against healthy baselines - memory pressure reports "spiked to 100% - 0σ above its 100% baseline" #1996 records what under-qualified anomaly findings do to trust.
• Accepting the latency because client-side timeout monitors page first. That is the status quo, and it is what surfaced this incident. It leaves the tool describing outages it watched happen.

Query Store independence is a requirement, not a convenience

On at least one production store class the Query Store readers are deliberately disabled (#2296) — which is the deployment this incident happened on, where the plan-count evidence had to come from outside the product. A pileup detector that reached for query_store identity would compile, test green against a QS-enabled fixture, and ship blind on exactly the servers that needed it.

So the trigger, the baseline, the statement identity and the incident fingerprint are computed from the active-query snapshot collector alone, and the statement key is the DMV's own query_hash off sys.dm_exec_requests rather than anything Query Store hands out.

SameStatementPileupSourceCensusTests pins this from source, for the detector and both editions' readers (enumerated rather than intersected — a census that checks one SKU certifies only that SKU):

• no query_store identifier in code or in SQL literals on the trigger path (comments are exempt on purpose — the detector's own remarks have to be able to explain why the dependency is forbidden; this is the inverse of the delivery census's strip-the-strings rule, because here a table named inside a literal is the dependency under test);
• every FROM/JOIN target in the readers' literals is one of the permitted collector tables, and the detector's literals name none at all (it is a pure function of rows);
• the fingerprint is a pure function of (server, database, statement identity) — no store read, nothing a disabled Query Store could withhold.

PLAN_REGRESSION and the #2138 force-plan bot stay exactly what they were: follow-on enrichment where QS happens to be readable, never the trigger.

Thresholds, derived from fleet distributions

Pulled live from the Darling store's active-query snapshots: four production servers × 24 hours, ~4,160 snapshot instants. Same-statement concurrent groups: 484 at n ≥ 2, 103 at n ≥ 3 — but only four n ≥ 3 groups had every session past ten seconds, and three of those four are routine batch shapes. Each constant is named per #3060 with its derivation stated on it, in the unit the gate compares (#3463).

Constant	Value	Why that value
MinConcurrentSessions	3	n ≥ 2 groups number 484 in four server-days and are full of ordinary paired workloads (job pairs, two-lane ETL, index maintenance). Three concurrent copies is where a shared plan flip shows itself — which is what two coincidentally-slow sessions do not prove.
MinElapsedMs	10,000	The victims died at the client's 30-second timeout; a 10 s floor pages while they are still alive. The measured pack cleared it with 2.7× headroom (min 27,703 ms). Below it the fleet's 5–10 s band holds routine permission-cache rebuilds at n ≥ 3.
MinIoWaitSessions	1	The mechanism gate. One, not two, because page-IO waits are millisecond-scale — the incident's suspended copies showed wait_time_ms 5 — so sessions bounce between suspended and runnable and demanding two simultaneously suspended makes the gate a coin flip on sampling phase. The incident showed two; requiring one keeps the evidence without betting the page on sampling luck. Specificity comes from the conjunction.
IoClassWaitPrefixes	PAGEIOLATCH_, IO_COMPLETION, ASYNC_IO_COMPLETION, WRITELOG, WRITE_COMPLETION	The measured shape plus the same mechanism on other IO paths. BACKUPIO/BACKUPTHREAD deliberately excluded — a backup convoy is not a plan flip.
BaselineLookbackMinutes	45	Long enough to catch a fast statement in flight at the ~1-minute snapshot cadence (the measured statement was observed at 54 ms 3.5 minutes before), short enough that the window self-clears after an episode — a fired pileup leaves 27-second rows in it, so the same statement cannot re-fire until they age out. That quiet period is deliberate and sits near the notify cooldown's floor.
SubSecondBaselineCeilingMs	1,000	The issue's own wording, and the measured in-window observation was 54 ms — 18× under. A single recent multi-second observation means the statement was already slow, which is a different finding's beat.
MinBaselineObservations	1	A statement never seen before the pileup has no "normally sub-second" to betray. The fleet's loudest counterexample (a sync job at n = 5, all past 13 s) has zero priors and is excluded by exactly this. Thin alone; load-bearing only in the conjunction, which measured clean.
StaleSnapshotCutoffMinutes	10	The staleness rule the long-running-query alert already applies to this table (#1812's shape): a collector outage must not hold a level-triggered evaluation firing on frozen rows.

The measured incident clears every gate; ordinary workload does not. The three non-incident fleet shapes that reach n ≥ 3 past ten seconds each fail a different gate, which is the argument that no single threshold is carrying the finding:

• an inventory-sync job (n = 5, all past 13 s) — zero IO-class waits, and no prior observation;
• a permission rebuild (n = 3, past the floor) — priors already at 11.9 s, so never sub-second;
• a nightly catalog scan (n = 3, 24 s, on page IO) — no baseline observation at all;
• and a slow shipment statement with a 2-second prior — over the baseline ceiling: already-slow getting slower, not a flip.

All four are tests.

Severity calibration, in the unit the gate compares

severity = min(2.0, sessions × min-elapsed-seconds ÷ 40). Stated to the figures the arithmetic actually produces, because a calibration claim stated in a rounded unit is not the claim the gate evaluates (#3463):

Shape	Session-seconds	Severity	Pages?
Measured incident (3 × 27.703 s)	83.109	2.0777 → capped 2.0	yes — 0.578 above the gate
Notify boundary (3 × 20 s, 4 × 15 s, 6 × 10 s)	60	1.5	yes (gate is >=)
Just under (3 × 19 s)	57	1.425	no
Minimum firing shape (3 × 10 s)	30	0.75	no — visible, persisted, drill-downable
Any two-session pileup	—	no finding at all	no

The measured incident clears the gate even with two of its three sessions discounted to the 10-second floor. The notify boundary is three concurrent copies each past two-thirds of the timeout that killed the measured victims. And the issue's "a two-session brief pileup must not notify" holds one step stronger than asked: the session floor is a predicate, not a severity input, so two sessions produce no finding at 12 s, 29 s or 600 s.

Recurrence folds instead of surprising

The measured statement re-drew its regressed plan later the same evening after fully self-clearing, so the finding gets the incident-fingerprint treatment every alert family already has: the IncidentId recipe extended with the statement identity. Episode two lands on episode one's incident trail as an occurrence (occurrences / first_seen / last_seen via the existing (story_path_hash, incident_id) folding) rather than reading as a fresh surprise, and #2138 gets a trigger token stable across episodes, plan churn, restarts and QS resets. The story path carries the statement identity too, so muting or cooling down one statement's pileup cannot answer another statement's question (#3459's rule).

Stated plainly because it is a real behavior and not an accident: a recurrence inside the 6-hour notify cooldown folds silently rather than re-paging, because a band-saturating severity cannot satisfy the #2054 worsening step. The occurrence trail and the viewer show it; the channel does not repeat it. That is the house's standing-condition policy, and it is what "folds onto episode one rather than reading as fresh" means.

Both editions

Lite's active-query snapshots feed the same seam — one shared collector definition, one table shape — so the predicate, thresholds, severity arithmetic, fingerprint and noise filters live once in PerformanceMonitor.Analysis as a pure function of snapshot rows. Each edition contributes only its window reader (Npgsql over query_snapshots, DuckDB over v_query_snapshots) and its sweep call site. Both ship it.

It adds no delivery semantics — and is censused as the call site it is

The finding rides the existing analysis-finding machinery end to end: the mute registry, the two-phase materialize → enrich → persist write, occurrence folding, notify_severity, the incident-keyed cooldown and its worsening rule. It is, however, a new delivery call site on both SKUs — a different thing, and accounted for as one:

• each sits under ShouldNotifyAnalysisFindings (master AND family, alerts_enabled is not the master switch its contract claims: two delivery paths paged through a fleet-wide mute, 38 and 60 minutes in #3464's predicate) — production is unconditional, delivery alone is gated (the D0 split);
• each carries its own AlertMasterSwitchSurfaceTests census entry (Inline), and the pins hold both in both directions, with the predicate's call count raised from two to three;
• the README sentence that makes alerts_enabled a promise widened from "scheduled-analysis finding notifications" to "analysis finding notifications". The narrower wording described a promise smaller than the one the gates keep, and an operator could reasonably have read a non-scheduled finding as escaping the switch — the exact class of confusion alerts_enabled is not the master switch its contract claims: two delivery paths paged through a fleet-wide mute, 38 and 60 minutes in #3464 was about.

One read-side change, in both stores, for the same reason

The latest-batch read now excludes pileup rows from defining MAX(analysis_time) and overlays the ones newer than it. #2448's contract is that the newest batch is one indivisible statement about a server — the complete output of one pass — and a per-sweep row claiming the MAX would replace the last complete analysis with a single-row one, making a server read healthier mid-incident. That is #2448's own misreading arriving through the write cadence instead of through a torn batch. The overlay is self-limiting (visible from firing until the next scheduled pass completes, then living on in the windowed reads and its incident trail), and the epoch fallback keeps a pileup visible where no scheduled batch exists to anchor on — never a disabled-analysis deployment (the pileup sweep rides the same analysis-enabled gate, so analysis off means no pileup rows either), but a young install whose pileup fired before the scheduled pass's 24-hour data-span gate let a first batch exist, or analysis toggled off after pileup rows landed and before any scheduled batch did. Both stores carry the identical shape and are pinned against each other.

Migration rung

None claimed, and none needed. The finding persists through analysis_findings' existing columns, reads query_snapshots' existing columns, and keeps its one piece of cross-sweep state — the last-evaluated snapshot instant — in memory, where a restart costs at most one repeated evaluation whose finding folds onto the same incident id and whose notification the cooldown (seeded from the alert log on first lookup) suppresses. The stamp advances only once the instant's outcome is durable — evaluated clean, fully muted, or persisted — so a transient store fault re-derives the same instant on the next sweep instead of losing a firing instant's finding, and the same folding-and-cooldown absorption covers the replay; the ordering is pinned from source on both call sites. The rung available to this lane is left unspent.

Tests

The measured incident reconstructed verbatim from the store's own rows, and the shapes that must stay quiet:

• the 20:10:31Z incident — fires at notify-eligible severity, with the statement identity, the session/elapsed evidence, the drill-down's three sessions (worst-first, with waits and reads) and its baseline row, and the frozen value-stated advice quoting the measured wait type;
• the 20:07:01Z pre-incident snapshot — must not fire;
• busy-but-healthy — eight concurrent sessions, all deep, all on page IO, all on different statements, each with its own sub-second baseline: must not fire;
• a long-running single session (an hour deep) — must not fire; that is long_running_query's job;
• two sessions at 12 s / 29 s / 600 s — must not fire;
• the fleet's other three deep groups — each failing a different gate;
• no-IO, stale-snapshot, noise-shape (sp_server_diagnostics / WAITFOR / backup), one-deep-copy-among-fast-siblings, and duplicate-session-rows — must not fire;
• the onset-poisoned sequence — first sample at ~5 s (no finding: the floor), second sample past the floor (still no finding: the ceiling gate reads the onset rows) — pinned as the accepted blind spot, with the counterfactual (the identical second instant, onset sample absent) firing;
• episode folding — episode two shares episode one's incident id and mute key, while the fingerprint still separates statements, databases and servers, and two statements piling up at once produce two distinct findings;
• severity — pinned at six points with the notify boundary expressed in session-seconds, plus the formula's unit identity (severity × divisor == session-seconds) so the divisor cannot drift from its doc comment;
• QS independence — pinned behaviorally (the snapshot row type is the input contract, enumerated member by member) and structurally (the three-file source census).

Verification, and its limits

Every touched assembly builds, plus the whole solution: PerformanceMonitor.Analysis, Darling.Analysis, Darling.Service, Lite, Darling.Tests, Lite.Tests.

The test projects target net10.0-windows and cannot execute on this machine, so the assertions were additionally replayed out of band against the real code: PerformanceMonitor.Analysis is net10.0, so a throwaway net10.0 console harness ran the detector itself over the same fixtures (102 checks, all passing), and a second harness replayed the census logic — the #3465 file-set derivation, per-member site counts, Inline gate ordering, the notify pins, the #3467 QS-independence and store-SQL pins, and the dedup-stamp ordering pin — against the worktree with the test project's own CSharpSourceWalker copied in verbatim (93 checks, all passing), with its census table verified content-identical to the committed one. What that does not cover: the xUnit runner's own discovery/attribute handling, and anything requiring a live store — the two readers' SQL is verified by column-name audit against the collector definition and both generated schemas, and by shape-match against the existing long-running-query read of the same table, not by execution.

What this cannot see

An episode whose own onset poisons its baseline. If the collector's first sample of an episode lands while the sessions are between the sub-second ceiling and the elapsed floor — 1–10 s in — that instant correctly does not fire (the floor), and its rows then sit in the 45-minute lookback as multi-second priors: every later instant of the same episode fails the sub-second baseline gate against them, and the episode never fires at all. It fails quiet — a missed page, never a false one — and the exposure is sampling phase: a 9-second landing band in a 60-second collection cycle, roughly 9-in-60 on the measured 90-second shape (under ~1 s the onset rows are themselves sub-second and reinforce the baseline; past 10 s the first sample fires directly). Accepted deliberately: both repairs are gate changes — onset-exclusion, or pricing on the qualifying subset past the floor — each with edges of its own, and neither ships ahead of a measured miss to calibrate against. The recurrence watch is the instrument that would produce one: episodes fold onto a statement-scoped incident id, so a statement whose trail holds fired episodes alongside snapshot-visible pileups that produced no finding is the reopen shape. The detector's remarks carry the full statement, and the poisoned sequence is pinned as accepted behavior, counterfactual included.

The same reopen shape covers the gate's fresh-arrival dilution: a caller that joins the convoy just before the sample resets the pack's minimum below the floor and suppresses detection while the pileup is growing. The qualifying-subset alternative fixes both edges at once; it waits on re-deriving the fleet calibration, which was measured under the every-session predicate.

Deferred, deliberately

• The waiting-task collector as a second input. The issue names it among the permitted inputs, and the 20:10:34Z sample corroborates the episode (including a tempdb WAIT_ON_SYNC_STATISTICS_REFRESH, plausibly the recompile trigger itself). The trigger does not need it — wait_type and status ride on the snapshot row, which is where the IO-class evidence comes from — so adding a second per-sweep read for drill-down enrichment alone was not worth doubling the reader surface on a rarely-fired finding. It is deliberately not in the census's permitted-tables set: pre-cleared, the read could arrive later without touching a census line, which is the opposite of what the census is for. Adding it means widening the permitted set in the same change — the census fails, names the file, and the dependency lands as a recorded decision.
• Operator-tunable thresholds. The four shape constants stay in code for now; notify_severity is already the operator's knob over whether a given pileup pages. A control-plane knob rung is available if the fleet shows a deployment that needs a different shape.

[claude]

Correctness: grouping by StatementIdentity (query_hash) alone, without DatabaseName, can conflate unrelated slow queries in different databases into one bogus "shared plan" pileup.

query_hash is computed from the normalized query text and is not scoped to a database — two different user databases running textually-identical parameterized SQL (a very common shape in exactly the multi-tenant-per-database SaaS deployments this finding targets) produce the same hash. But the entire causal story this detector tells ("a shared parameterized plan flipped, every caller of that one plan piles up together") is only true within one database, because a SQL Server plan-cache entry is keyed per-database (dbid is part of the compiled-plan cache key) — a plan going bad in database A cannot be "the same plan" as one in database B, even for byte-identical text.

Concretely, three sessions in three different databases, each independently slow (unrelated causes) for >10s on a query shape that happens to share a query_hash, with one on an IO wait, would be merged here into a single SAME_STATEMENT_PILEUP finding — miscounted as "3 concurrent sessions piled up on one statement in {one arbitrarily-picked db}" and paged at a severity computed from the combined (unrelated) session count.

This also affects:

• The baseline check at line ~317-320 (StatementIdentity(r) == identity, no database filter): a genuinely-new slow query in DB B could pass the "normally sub-second" baseline gate using DB A's unrelated fast history for the same hash — or a real same-DB pileup could be suppressed because an unrelated slow occurrence of the same hash in another DB pollutes the baseline's sub-second ceiling check.
• databaseName at line 390 (pack.Select(r => r.DatabaseName).FirstOrDefault(...)): picks one database out of what could be a multi-database pack, non-deterministically (row order isn't guaranteed stable for ties at the same collection_time). Since ComputeIncidentId folds on (serverName, RootFactKey, databaseName, identity), this can also make the same recurring incident fold onto different incident IDs across evaluations if the "first" database picked changes — undermining the occurrence-folding guarantee this PR is built around.

Worth scoping the grouping (and the baseline lookup) to (DatabaseName, StatementIdentity) rather than StatementIdentity alone, matching how a plan-cache entry is actually scoped.

[erikdarlingdata]

Real finding, all three parts — and it's now #3474 rather than a quiet default, because the fix has a fork in it: the measured incident's convoy may itself have spanned tenant databases ("ten tenants inherited the flip together"), in which case scoping the group key per-database would have missed the exact outage this detector was built for. The issue lays out both options plus the deciding evidence (the incident's own snapshots record DatabaseName per session — that lookup happens before any code moves). The FirstOrDefault fold-attribution nondeterminism is real under every option and flagged to ship first.

[claude]

Reviewed the same-statement-pileup finding (#3467): detector, both SKUs' readers, worker/service wiring, finding-store overlay SQL, advice, and the extensive pinning tests (census, master-switch, calibration).

Overall: well-scoped and heavily self-verified — the source-census tests keep the trigger path off Query Store as claimed, the master-switch surface tests keep delivery gated identically to the scheduled path, and the calibration/severity math checks out against the fleet numbers cited in the docstrings. Lite and Darling stay in lockstep (same detector, same D0 production/delivery split, same dedup-stamp-after-persist discipline, same latest-batch carve-out SQL shape, verified by BothFindingStores_CarveThePileupRowsOutOfTheLatestBatch_Identically). Confirmed separately that Lite has no PostgreSQL target seam at all, so the missing engine guard in RunPileupSweepAsync (present in Darling's EvaluateSameStatementPileupAsync) isn't a parity gap — it's dead code that can't apply there.

Left one inline finding: SameStatementPileupDetector.Evaluate groups candidate pileups by StatementIdentity (query_hash) alone, without DatabaseName. Since query_hash isn't database-scoped but SQL Server's plan cache is (a plan flip in one database can't be "the same plan" as another database's), this can conflate unrelated slow queries across databases into one bogus finding, pollute the sub-second baseline check cross-database, and make incident-id folding non-deterministic when the pack spans databases. Recommend scoping the group/baseline key to (DatabaseName, StatementIdentity).

No SQL injection, secrets, or file/network/process concerns — all reads are parameterized ($1/$2 or DuckDBParameter), and no T-SQL was touched by this PR (the shared collector query itself is pre-existing).

[claude]

Review: SAME_STATEMENT_PILEUP finding (#3467)

Went through the full diff — detector (SameStatementPileupDetector.cs), both SKUs' readers (PgPileupSnapshotReader.cs / Lite/Analysis/PileupSnapshotReader.cs), both worker integration points (DarlingWorker.cs / CollectionBackgroundService.cs), the GetLatestFindingsSql carve-out in both FindingStores, the census tests, and both test suites (~1080 new test lines).

Correctness

• Predicate logic (session floor, elapsed floor, IO-wait gate, sub-second baseline, staleness cutoff) checked against the test fixtures line-by-line — matches, including the distinct-session-vs-row counting, the worst-first/newest-first drill-down ordering, and the severity arithmetic (sessions × min-elapsed-seconds ÷ 40, capped at 2.0).
• Verified PileupWindowSql's column list against QuerySnapshotsCollector's actual schema (session_id, query_hash, wait_type, total_elapsed_time_ms, logical_reads, reads, is_cdc_capture, etc.) — all present, and the session_id > 50 / is_cdc_capture filters match the existing long-running-query read of the same table.
• GetLatestFindingsSql's carve-out (exclude pileup rows from defining MAX(analysis_time), overlay them while newer) is naive-UTC-consistent with the timestamp (not timestamptz) column, so the TIMESTAMP '1970-01-01' epoch fallback compares cleanly.

Lite/Darling parity

• Detector and its constants live once in PerformanceMonitor.Analysis, so predicate/severity/fingerprint logic can't drift between editions by construction.
• Darling's worker gates the sweep on Target.Engine != PostgreSql since Darling also monitors Postgres targets that never populate query_snapshots; Lite has no equivalent check, but Lite's ServerConnection/collector surface is SQL-Server-only (no Engine discriminator on the model), so there's no Postgres case for it to filter — not a parity gap.
• The GetLatestFindingsSql carve-out is byte-identical in shape between PgFindingStore and Lite's FindingStore, and the census test pins them against each other.
• Darling needs its own NextPileupSweep cadence stamp because its alert-sweep loop runs on a finer tick than the collector; Lite's collection loop tick is the collection cadence, so evaluating on every tick without a separate stamp is correct, not an oversight.

Security: no injection surface — both readers use parameterized queries throughout, no string-built SQL.

One minor nit (style, not a bug): PgPileupSnapshotReader.cs:99 binds the naive-UTC timestamp inline via DateTime.SpecifyKind(windowFloorUtc, DateTimeKind.Unspecified) rather than through a local AsNaive() helper. CONTRIBUTING.md calls this out explicitly under the Darling PostgreSQL conventions ("Several files keep a one-line Naive() helper for exactly this; use it rather than binding a DateTime straight through"). Functionally correct either way since there's only one timestamp parameter in this file, so take it or leave it.

Otherwise didn't find a correctness, parity, or security issue to flag — the census tests and the fleet-shape counterexamples in SameStatementPileupDetectorTests cover the edge cases I'd normally probe for (two-session pileups, mixed-statement concurrency, stale snapshots, duplicate session rows, null query_hash).