[OffgridwithJD]

Stacked on #1467 (merge after it). Two commits: 4edf4a78 (the twin and the shell fixes) and 5f31e7c2 (the ledger re-dating). This is my guess at item 70's third suite, the one cut off as test/nativ…. It's a twin-less native suite whose arms postdate 2026-09-09, and it sits next to recluster.

What was wrong

With an online compaction never reserving from a freed range (reusedOffset = false && PgColumnarAllocateFreeSpace(...)), the shell stayed 36/36 green. The suite exists to prove that reuse. Measured why:

• The repeated reclusters did nothing. The four recluster('n', 'id') calls after the first each returned 0: recluster self-gates on a table already in that key's order. They wrote nothing, so the file "plateaued" at 311296 with reuse disabled. They now alternate v and id, and a new arm, "each repeated recluster rewrote the table, so none was skipped as already ordered", requires each call to rewrite. Without reuse the file then grows 311296 → 901120 and the plateau arm goes red.
• "free space is being reused (bounded, not growing per cycle)" asserted free_space > 0, which is the arm before it again. It now compares with the count after the first cycle and goes red as 1 → 5 rows.

Red first (PG18)

mutant	old shell (36)	new shell (37)	twin
no reservation from a freed range	green	red: the plateau and free-space-bound arms	red: plateau (311296 -> 901120)

Fifteen more mutations redden their own arm in all three. The old shell already saw them, but the ledger had them never:

• compact_rewrite's guard without isnan, without < 0, without > 1, strict at 0.0, strict at 1.0;
• maintenance_due with NULL, negative or above-1 accepted for the compact threshold, and the same three for the recluster threshold;
• maintenance_due refusing the 0.0 or the 1.0 boundary;
• compact_rewrite_due pinned false, and pinned true.

The twin

test_native_reclaim.py carries all 37 checks by the shell's name in three tests, one per fixture (compare_to_bash: 37 literal, 0 missing). SQLSTATEs are read from exc.sqlstate, so a failure without one can't read as "OK". maintenance_due's eight refusals are a loop table. So the loop-reader guard's list of such files gains native_reclaim: that guard exists so that change shows up as a diff.

Runs

Head is 37/37 in both twins on each of 15, 16, 17, 18 and 19.

Ledger

• The suite had 36 rows, 2 of them dated. The new arm enters never, and 17 rows are newly dated by sixteen mutations:
  • no reuse (2 arms);
  • compact_rewrite's guard (5);
  • maintenance_due's guard and verdict (10).
• The max_groups arm was already dated, and its mutant (cap ignored: 10|0|0) still reddens it.
• Still never:
  • the controls;
  • the data-parity arms. A shifted reuse offset reddened the plateau and cap arms, not the data, so I didn't seed it.
  • maintenance_due's NaN arms. NaN is redundant with > 1.0 under PostgreSQL's float ordering, as the SQL's own comment says.
• The census is 3901 / 2828 / 1073. suites_not_covered doesn't move (209), and pgc_ledger.py gate returns rc 0.

Counts and guards

• cluster_tests 687 → 690, and pytest collects 690.
• COMPLETE gains native_reclaim, and TESTS.md gains §155.
• The NO_CLUSTER guards pass (438), harness_selftest.sh passes, and docs_style.sh passes.

🤖 Generated with Claude Code

[jdatcmd]

Approving 5f31e7c.

Measured on PG17, at 5f31e7c: native_reclaim.sh 37/37, and test_native_reclaim.py 37 checks over 3 tests. The tsv is 3901 / 2828 / 1073, as described.

Your reuse claim, run myself: reusedOffset = false && PgColumnarAllocateFreeSpace(...) in columnar_write_state.c.

suite	result
main's native_reclaim.sh	36/36 green: the suite that exists to prove reuse couldn't see it off
this PR's	35/37: repeated recluster reuses space (file plateaus), and free space is being reused (bounded, not growing per cycle) got [no (1 -> 5 rows)]
the twin	the plateau arm, got 'no (311296 -> 901120)'

Alternating the recluster keys is what makes it measurable: the same-key reclusters returned 0 and wrote nothing. I took the fifteen guard and verdict mutants from your table.

[jdatcmd]

@OffgridwithJD, thanks for restating the stack. I'm checking it now, and found one regression in it.

The restate dropped two edits to the loop-reader guard's file list in test_compare_to_bash.py:

• this PR's twin commit a5764b3 (was 4edf4a7) no longer adds native_reclaim;
• test: native_repack gets its pytest twin, and "the supported alternative" must reclaim (#1341) #1469's twin commit 2476bfb (was 3f575cd) no longer adds native_repack.

I compared each commit's patch before and after the restate, and only those lines differ. At the top of the stack (#1474, 46db379), test_compare_to_bash.py fails:

FAILED test_compare_to_bash.py::test_the_loop_reader_invents_nothing_in_this_corpus
and it is these files, …: got 'build_refusal, differential, join_runtime_filter, native_reclaim, native_repack, native_vacuum_race, sorted_pathkeys' want 'build_refusal, differential, join_runtime_filter, native_vacuum_race, sorted_pathkeys'

So from #1468 up, the guard's CI job will go red. The fix is to restore those two lines in a5764b3 and 2476bfb. Everything else I've compared so far is unchanged apart from the ledger and the counts: #1450's fix commit is patch-identical, and the other changed commits are ledger seeds. I'll finish checking the bookkeeping and re-approve #1450 → #1467 as soon as that's done, since the dropped lines are above them.

[jdatcmd]

Re-approving 8c74c45. The upper stack's range-diff against the previous restate (base 62c80a4) shows only the two restored guard-list lines, in fd5c9cb and 7e8d310; every other commit is unchanged. test_compare_to_bash.py passes at the top (5b03158), 40/40, with the list naming native_reclaim and native_repack.

[jdatcmd]

@OffgridwithJD, the prefix #1450 → #1467 has merged. #1468 → #1474 are re-approved on their fixed heads, and I'm merging them in order as each goes green, unless you say hold.