From c21641c2d43b3bc719ed558c05800f1d793ab78f Mon Sep 17 00:00:00 2001 From: OffgridwithJD Date: Wed, 2 Sep 2026 23:18:45 +0000 Subject: [PATCH] docs: the drop_cleanup arms do not cascade, and they re-baseline Comment-only, one file, executable content identical to main. #879 shipped a sentence I have since disproved against the file it describes: "The first four are relative -- each compares a snapshot against the previous one, so they cascade once the first leaks." They do not cascade. `base` is re-captured immediately before each of the four arms, so a leak that has already happened is absorbed into the next baseline rather than inherited. Each arm measures the increment ITS OWN step adds. That is why all four redden under the DROP-hook mutation -- four independent detections, because every drop leaks -- instead of one detection and three echoes. The evidence was already in the numbers I published: every `want` is the previous `got`. jdatcmd raised this and I checked it against the file rather than taking it. The half of his objection that did NOT survive is worth recording too: he also read the last sentence as inverted, and it is correct. A standing leak that no single step increases gives every relative arm a zero increment, so all four pass and only the absolute arm -- whose expected value is the literal 0 -- can fire. He withdrew that half himself after testing the scenario it names. NO LINE NUMBERS. The suggested edit cited :44, :53, :67 and :80, which were main's offsets BEFORE #879 added twenty-one comment lines; on main today those are a Usage comment, `snapshot()`, an INSERT and a different check. My own first draft of this fix then cited :65, :74, :88 and :101 -- correct before the edit and wrong after it, because the replacement paragraph is longer than what it replaces and shifted the lines it pointed at. Twice in one file, in opposite directions. The comment now says to grep `base="$(snapshot)"` and says why. Green: drop_cleanup 8/8 and docs_style 9/9 on pg18a and pg19a. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01EtQbQUiMSpGWembJV1jxob --- test/drop_cleanup.sh | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/test/drop_cleanup.sh b/test/drop_cleanup.sh index 6ee13d80..0b773c74 100755 --- a/test/drop_cleanup.sh +++ b/test/drop_cleanup.sh @@ -36,10 +36,22 @@ # this file is the one to run for that call site, which is not obvious from # either file's subject: alter_am_cleanup is named for SET ACCESS METHOD. # -# Note the shape of the five. The first four are relative -- each compares a -# snapshot against the previous one, so they cascade once the first leaks. Only -# "no storage row refers to a missing relation" is absolute (got [25] want [0]), -# and it is the one that would still redden if the baselines degraded together. +# Note the shape of the five. Four of them re-capture `base` immediately before +# their own work. Grep `base="$(snapshot)"` to find them, once per arm: a line +# number cited here shifts every time this comment is edited, which is how the +# first draft of this paragraph came to cite four lines that had moved. +# +# So each of the four measures the increment its own step adds rather than +# inheriting an earlier failure. They do NOT cascade: a leak that has already +# happened is absorbed into the next baseline. That is why all four redden +# under the mutation instead of one reddening and three following -- every drop +# leaks and each arm detects its own. The `want` values show it: each is the +# previous `got`. +# +# The fifth, "no storage row refers to a missing relation", is absolute +# (got [25] want [0]). It covers the case the other four cannot see by +# construction: a STANDING leak that no single step increases gives every +# relative arm a zero increment, so all four pass and only this one fires. # # Usage: test/drop_cleanup.sh [PG_CONFIG] # Written fresh for pgColumnar.