[OffgridwithJD]

@jdatcmd This fixes the one remaining red on #1757. #1759's dispatch (run 40376459928) went green on the capability sweep. Its only failure was pytest (cluster tests, PG 17), on one premise in my #1444 twin:

FAILED test_native_backend_crash.py::test_a_kill_after_the_stripes_flushed - AssertionError:
crashB: the INSERT had written pages before the kill (the relation grew): got 'False' want 'True'

Cause: the scenario order, not the product

• A killed write's stripe reservation (the metapage highwater, PgColumnarReserveOffset) is WAL-logged but unflushed, while its pages already extend the file.
• If the walwriter hasn't flushed it by the SIGSEGV, redo restores the old highwater over blocks that physically exist.
• The next write fills those blocks before it extends anything. crashA kills a 3M-row INSERT once the relation grows, and crashB's 100k rows then fit entirely inside crashA's leftover, so the relation never grows.

Reusing blocks no durable reservation covers is correct: every content, row-group and mirror check passed in that run.

Measured on local PG 17: crashA's pattern, then a committed 100k-row INSERT.

wal_writer_delay	relation grew after the 100k INSERT
10s (unflushed at the kill)	no, 3 of 3 runs
200ms (default)	yes, 3 of 3 runs

Fix, in both suites

• Pin wal_writer_delay = 10s (its maximum) in the private cluster, so the race always goes the losing way instead of depending on runner load.
• Run crashB first, where its only predecessor is the committed baseline, whose commit flushed its reservation. crashA and crashC write 3M rows, which outgrow any leftover.

Evidence (PG 17)

state	shell	pytest
pin only, old order (red-first)	27 passed + 1 failed, crashB premise	19 pass + 1 fail, crashB premise
pin + reorder	5 of 5 green, 28 checks	5 of 5 green, 28 checks

• Tried and rejected: a WAL flush from an observer just before the kill (committing an xid). The writer can reserve another stripe between the flush and the kill, and the shell went red 1 time in 3.
• Gates: guards 847 passed. Collection 4332 equals cluster_tests. Census 4567 equals the tsv. Ledger gate rc=0. Harness self-test passed.
• Ledger: no check is added, renamed or redated, so the ledger and census are untouched.

Once this merges, a dispatch of nightly.yml on main should close #1757.

🤖 Generated with Claude Code

[jdatcmd]

Approved on 3723d97c.

First, a correction. On #1283 I wrote that space reuse is not the cause. I was wrong. My probe ran with the default wal_writer_delay (200 ms). The walwriter flushed the reservation before every kill, so I saw no gap in 12 crashes and dropped the idea. Your 10 s pin is the control I lacked.

What I reproduced (local PG 18, pytest twin, main 6ae11a38 plus this PR):

state	result
main's file plus the wal_writer_delay = '10s' pin only, old order	red 4 of 4: crashB: the INSERT had written pages before the kill (the relation grew): got 'False' want 'True', the same message as the nightly
this PR's file	green 5 of 5, 3 passed each

What I checked by reading:

• The order holds in CI. pytest-cluster runs pytest without -n, so module order is collection order. The shell runs top to bottom.
• crashA and crashC still prove their premise after the reorder. Each waits for pg_relation_size to pass size0, and a 3M-row write outgrows any leftover from an earlier kill. So their premise checks still mean what they say.
• The pin is set once in the private cluster (nbc / the suite's own setup), so no other suite inherits it.

Not verified by me: the shell twin. The only PG 17 install here is root-owned and holds an older build. I'm relying on CI's suites jobs for it, and I'll merge only at 15/15.

On the follow-up: yes, please surface the INSERT's error in both twins. It wasn't the cause this time, but a swallowed error would leave the next red unexplained.