Location: src/backend/access/heap/vacuumlazy.c:3152 Mechanism: unsigned-wrap: removal of possibly_freeable > 0 guard on BlockNumber (uint32) allows wrapped subtraction to spuriously trigger truncation when nonempty_pages > rel_pages Failure: spurious should_attempt_truncation true on wrapped possibly_freeable, leading to unnecessary AccessExclusiveLock acquire and rescan in lazy_truncate_heap Verification status: refuted Verification method: static-analysis-plus-compiled-reproducer Verification evidence: Compiled C reproducer (gcc) confirms that on uint32, x > 0 is equivalent to x != 0; a wrapped value (e.g. 4294967291) is non-zero so possibly_freeable > 0 evaluates TRUE for the wrap in BOTH old and new code. The old guard never rejected unsigned wraparound. The zero case (nonempty_pages == rel_pages) is correctly rejected by both old (0 > 0 = false) and new (0 >= 2 = false) code. The downstream lazy_truncate_heap AE-lock recheck (vacuumlazy.c:3228-3239) handles the wrap case identically in both versions. No regression introduced by this patch.

Repair: not-applicable-refuted (all repair sub-objects carry status: not-applicable-refuted).

Location: src/backend/access/heap/hio.c:335 Mechanism: cross-file invariant breakage: REL_TRUNCATE_MINIMUM lowered from 1000 to 2 is no longer 'way larger' than MAX_BUFFERS_TO_EXTEND_BY (64) as documented in hio.c:335-337 comment; the comment is now false and misleading Failure: stale safety comment misleads future maintainers; increased AccessExclusiveLock contention on small busy tables as autovacuum may consider truncating just-extended pages (data loss prevented by lazy_truncate_heap AE-lock recheck at vacuumlazy.c:3228-3239) Verification status: verified Verification method: source-inspection Verification evidence: hio.c:239 defines MAX_BUFFERS_TO_EXTEND_BY=64; hio.c:335-337 comment states 'REL_TRUNCATE_MINIMUM is way larger'; staged diff sets REL_TRUNCATE_MINIMUM=2 < 64. The invariant is inverted. lazy_truncate_heap re-reads RelationGetNumberOfBlocks under AccessExclusiveLock (vacuumlazy.c:3228) and bails if new_rel_pages != orig_rel_pages (3229), preventing data loss. Repair patch compiles clean with gcc 15.2.0 full project CFLAGS.

Repair instruction: Update the hio.c comment to state REL_TRUNCATE_MINIMUM is no longer guaranteed larger than MAX_BUFFERS_TO_EXTEND_BY and document the AE-lock recheck safety mechanism. Update the vacuumlazy.c comment to describe the new additive threshold predicate and its integer-division step behavior. Files: src/backend/access/heap/hio.c, src/backend/access/heap/vacuumlazy.c Postcondition: The hio.c comment accurately describes the relationship between MAX_BUFFERS_TO_EXTEND_BY and REL_TRUNCATE_MINIMUM and documents the safety mechanism relied upon. The vacuumlazy.c comment accurately describes the new predicate.

Code example (exact-postimage, `c):

	 * Note: REL_TRUNCATE_MINIMUM is no longer guaranteed to be larger than
	 * MAX_BUFFERS_TO_EXTEND_BY.  A concurrent autovacuum may therefore
	 * consider truncating pages that were just bulk-extended; that is safe
	 * because lazy_truncate_heap re-reads the relation size under
	 * AccessExclusiveLock and rescans the tail before actually truncating.
	 */

Patch: unified-diff, applies_to_head=926627bf9021137af66ac3bf21d1595af64ec66b, sha256=ae5fc6d32d43a4f80bf9194a5fc0d2a786911cf5ac79c8a940408b4f54c5dff9

Repair validation: status=passed, methods=apply-check, diff-check, compile, static-check Commands: git worktree add --detach <scratch>/verify-wt 926627bf9021137af66ac3bf21d1595af64ec66b; git apply --check repair_combined.diff; git apply repair_combined.diff; git diff --check; gcc -Wall -Wmissing-prototypes ... -I<worktree>/src/include -D_GNU_SOURCE -c -o hio.o src/backend/access/heap/hio.c; gcc -Wall ... -c -o vacuumlazy.o src/backend/access/heap/vacuumlazy.c; grep -c 'way larger' src/backend/access/heap/hio.c Evidence: Both hio.o and vacuumlazy.o compiled cleanly with gcc 15.2.0 and the full PostgreSQL project warning set (-Wall -Werror=vla -Wstrict-prototypes etc). No warnings emitted. Static check confirms stale 'way larger' phrase removed. Patch applies cleanly to frozen HEAD with no whitespace errors.

Test example: vehicle=inspection, files=src/backend/access/heap/hio.c Oracle: grep -c 'way larger' src/backend/access/heap/hio.c returns 0 Baseline: 1 (stale comment present before repair) → Patched: 0 (stale comment removed after repair)

Location: src/backend/access/heap/vacuumlazy.c:165 Mechanism: stale comment: comment describes old OR 'whichever is less' predicate but code now uses additive sum (rel_pages / REL_TRUNCATE_FRACTION + REL_TRUNCATE_MINIMUM) Failure: comment actively misdescribes the should_attempt_truncation predicate logic Verification status: verified Verification method: source-inspection Verification evidence: vacuumlazy.c:165-167 comment says 'REL_TRUNCATE_MINIMUM or (relsize / REL_TRUNCATE_FRACTION) (whichever is less)' describing the old OR predicate; vacuumlazy.c:3153 code is 'possibly_freeable >= vacrel->rel_pages / REL_TRUNCATE_FRACTION + REL_TRUNCATE_MINIMUM' which is an additive sum. Comment is stale.

Repair instruction: Replace the three comment lines describing the OR/whichever-is-less predicate with a description of the new sum predicate and its integer-division behavior. Also update the hio.c comment to reflect the new REL_TRUNCATE_MINIMUM relationship. Files: src/backend/access/heap/hio.c, src/backend/access/heap/vacuumlazy.c Postcondition: The comment accurately describes the should_attempt_truncation predicate.

Code example (exact-postimage, `c):

 * To consider truncating the relation, we require at least
 * (relsize / REL_TRUNCATE_FRACTION) + REL_TRUNCATE_MINIMUM
 * potentially-freeable pages.  Because relsize / REL_TRUNCATE_FRACTION uses
 * integer division, the threshold collapses to a constant REL_TRUNCATE_MINIMUM
 * for relations smaller than REL_TRUNCATE_FRACTION pages; relations of
 * REL_TRUNCATE_FRACTION pages or more add one page per
 * REL_TRUNCATE_FRACTION pages of size.
 */

Patch: unified-diff, applies_to_head=926627bf9021137af66ac3bf21d1595af64ec66b, sha256=ae5fc6d32d43a4f80bf9194a5fc0d2a786911cf5ac79c8a940408b4f54c5dff9

Repair validation: status=passed, methods=apply-check, diff-check, compile, static-check Commands: git apply --check repair_combined.diff; git apply repair_combined.diff; gcc -Wall ... -c -o vacuumlazy.o src/backend/access/heap/vacuumlazy.c; grep -c 'whichever' src/backend/access/heap/vacuumlazy.c Evidence: vacuumlazy.o compiled cleanly with full project CFLAGS. Comment-only change. Static check confirms 'whichever' removed. No warnings.

Test example: vehicle=inspection, files=src/backend/access/heap/vacuumlazy.c Oracle: grep -c 'whichever' src/backend/access/heap/vacuumlazy.c returns 0 Baseline: 1 (stale comment present) → Patched: 0 (stale comment removed)

Location: src/backend/access/heap/vacuumlazy.c:3153 Mechanism: undocumented integer-division step function: rel_pages / REL_TRUNCATE_FRACTION (integer division of uint32 by 32) collapses to 0 for rel_pages < 32, making the threshold a constant 2 for all relations under 32 pages Failure: threshold is a step function (constant 2 for <32 pages, +1 per 32 pages above) that is not documented; the old 1000-page minimum masked this behavior Verification status: verified Verification method: compiled-reproducer Verification evidence: Compiled C reproducer enumerating rel_pages 0..40 confirms rel_pages/32 is 0 for rel_pages < 32 and steps up by 1 every 32 pages. Threshold table: rel_pages=0..31 -> threshold=2; rel_pages=32..63 -> threshold=3; rel_pages=64..95 -> threshold=4. The F3 comment repair now documents this explicitly.

Repair instruction: Document the integer-division step function in the vacuumlazy.c comment (same edit as F3). Also update the hio.c comment. Files: src/backend/access/heap/hio.c, src/backend/access/heap/vacuumlazy.c Postcondition: The comment documents that the threshold is constant REL_TRUNCATE_MINIMUM for relations smaller than REL_TRUNCATE_FRACTION pages.

Code example (exact-postimage, `c):

 * integer division, the threshold collapses to a constant REL_TRUNCATE_MINIMUM
 * for relations smaller than REL_TRUNCATE_FRACTION pages; relations of
 * REL_TRUNCATE_FRACTION pages or more add one page per
 * REL_TRUNCATE_FRACTION pages of size.
 */

Patch: unified-diff, applies_to_head=926627bf9021137af66ac3bf21d1595af64ec66b, sha256=ae5fc6d32d43a4f80bf9194a5fc0d2a786911cf5ac79c8a940408b4f54c5dff9

Repair validation: status=passed, methods=apply-check, diff-check, compile, static-check Commands: git apply --check repair_combined.diff; git apply repair_combined.diff; gcc -Wall ... -c -o vacuumlazy.o src/backend/access/heap/vacuumlazy.c; grep -c 'collapses to a constant REL_TRUNCATE_MINIMUM' src/backend/access/heap/vacuumlazy.c Evidence: Comment-only change documents the step function; compiles cleanly. Static check confirms documentation added.

Test example: vehicle=inspection, files=src/backend/access/heap/vacuumlazy.c Oracle: grep -c 'collapses to a constant REL_TRUNCATE_MINIMUM' returns >= 1 Baseline: 0 (not documented) → Patched: 1 (documented in comment)

Location: src/test/regress/sql/vacuum.sql:192 Mechanism: no regression test added for the threshold change; existing vacuum.sql tests vacuum_truncate reloption but not the should_attempt_truncation threshold boundary Failure: threshold logic is otherwise untested; the arithmetic that regresses silently has no dedicated test Verification status: verified Verification method: test-suite-inspection Verification evidence: src/test/regress/sql/vacuum.sql lines 192-210 test vacuum_truncate reloption (TRUNCATE FALSE) but no test asserts that a relation with N trailing empty pages is/isnt truncated based on the threshold. No test covers the new rel_pages/32+2 formula.

Repair instruction: Add a regress test that creates a temp table with autovacuum_enabled=false, inserts 5000 rows, deletes id > 1000, vacuums, and asserts the relation shrank. Add a second case: insert 200 rows, delete all, vacuum, and assert the relation still has pages (behavior change). Add test: vacuum_truncate_threshold to parallel_schedule. Files: src/test/regress/sql/vacuum_truncate_threshold.sql, src/test/regress/expected/vacuum_truncate_threshold.out, src/test/regress/parallel_schedule Postcondition: pg_regress vacuum_truncate_threshold passes with expected output matching.

Code example (exact-postimage, `sql):

INSERT 0 5000

Patch: unified-diff, applies_to_head=926627bf9021137af66ac3bf21d1595af64ec66b, sha256=22af8e4139ea16ca4a30083c3399019d9e6c69b3fff9d55845c2e138766b9180

Repair validation: status=passed, methods=apply-check, diff-check, targeted-test Commands: git apply --check repair_f5_test.diff; git apply repair_f5_test.diff; psql -p 54335 -d postgres -f vacuum_truncate_threshold.sql Evidence: Test applies cleanly to frozen HEAD. Executed against patched PostgreSQL 18devel cluster: 5000-row case truncates (before=23 pages, after=5 pages, truncated=t). 200-row case confirms behavior change (relation retains pages). Output deterministic across two consecutive runs.

Test example: vehicle=regress, files=src/test/regress/sql/vacuum_truncate_threshold.sql, src/test/regress/expected/vacuum_truncate_threshold.out Oracle: truncated=t (23->5 pages); not_fully_truncated=t (200-row table retains pages after VACUUM due to threshold >= 2) Baseline: n/a (new test) → Patched: truncated=t, not_fully_truncated=t

Location: src/test/regress/expected/vacuum.out:242 Mechanism: existing regression test breakage: vacuum.sql lines 199 and 209 assert pg_relation_size('vac_truncate_test') = 0 is true after VACUUM, but the new threshold (rel_pages/32 + 2 >= 2) prevents truncation of tiny (1-page) relations that the old threshold (min(1000, rel_pages/16) = 0 for 1 page) allowed Failure: make check-tests TESTS=vacuum fails with 2 assertion mismatches: expected t got f at vacuum.out:242 and vacuum.out:269 Verification status: verified Verification method: targeted-test Verification evidence: Ran make -C src/test/regress check-tests TESTS=vacuum against patched code: 1 of 1 tests failed. regression.diffs shows 2 hunks where 't' expected but 'f' produced for pg_relation_size('vac_truncate_test') = 0. After applying the expected-output repair, the vacuum test passes (ok 1 - vacuum). The behavior change is intentional per the thread but the existing test was not updated.

Repair instruction: Update the two pg_relation_size('vac_truncate_test') = 0 expected results from ' t' to ' f' to reflect that tiny relations no longer truncate to 0 pages under the new threshold. Files: src/test/regress/expected/vacuum.out Postcondition: make check-tests TESTS=vacuum passes with the patched code.

Code example (exact-postimage, `diff):

f (1 row) DROP TABLE vac_truncate_test;

Patch: unified-diff, applies_to_head=926627bf9021137af66ac3bf21d1595af64ec66b, sha256=f9f6d0d6cb7aad47e013be16fd716ed2b31b749197adfbf982eaa43f81398e4a

Repair validation: status=passed, methods=apply-check, diff-check, targeted-test Commands: git apply --check repair_f6_vacuum_expected.diff; git apply repair_f6_vacuum_expected.diff; make -C src/test/regress check-tests TESTS=vacuum Evidence: Applied the expected-output patch on top of the staged diff; make check-tests TESTS=vacuum passes: 'ok 1 - vacuum 416 ms' / 'All 1 tests passed.' The 2 assertions now correctly expect f.

Test example: vehicle=regress, files=src/test/regress/expected/vacuum.out Oracle: pg_relation_size('vac_truncate_test') = 0 returns f (relation retains >= 1 page) Baseline: t (old code truncated tiny relations to 0) → Patched: f (new code does not truncate tiny relations to 0)