Repository navigation
test: native_ios gets its pytest twin (#1341) - #1508
Merged
Merged
Conversation
…dium projections assert their plans (#1341, #1339) test_native_fetch_bigcap.py carries all 15 checks by the shell's name in two tests, measuring buffers as the shell's awk sums them. Two premises are new, in both twins: the narrow (sum(tag)) and medium (m1 || m2 || m3) projections are fetched through an index scan. Only the payload query's plan was asserted. Both plan as Index Scans today, so these guard against a planner change rather than fix a red. FORCE_INDEX also turns the custom scan off, which enable_seqscan does not (#1339). Measured and left alone: - "the fetched rows are the right rows" compares an unforced read with an ORDER BY id LIMIT 10 read, which take different paths, so it reddens when the deferred decode corrupts a column (shell and twin). Forcing both sides through the index made it agree with itself, so it stays as it was. - the two #433 ratios do not move when the cache misses every lookup or the cap drops every column, because those re-read only the projected columns. #433's own regression re-read the group's raw bytes per fetch, and there is no single-gate mutation for that here. COMPLETE gains native_fetch_bigcap. TESTS.md section 173, cluster_tests 742 -> 744. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…by a deferred-decode mutation (#1341) The suite had no rows. suites_not_covered 193 -> 192; census 4347 rows / 3031 never / 1316 dated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"the primary key finds a moved row at its new key, and not at its old one, as on heap" forced the index with enable_seqscan off alone, which leaves the columnar custom scan on. Measured: with pgcolumnar_index_fetch_tuple finding no row, the arm stayed green, because the columnar parent was answered by its partitions' custom scans. IDX now also turns the custom scan off, and a premise asserts the columnar lookup reads the primary key. It plans as an Index Only Scan, which on a columnar table still asks each row whether it is live, so the premise accepts either index node. With the same mutation the arm is now red, in both twins. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…te-key arms are dated (#1339) Census 4348 rows / 3029 never / 1319 dated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…the index, and each refusal must be its own (#1341, #1339) test_sorted_projection.py carries all 29 checks by the shell's name in three tests. Under each of four mutations the twin reddens exactly the shell's set: the post-sort reindex removed, the compaction not sorting, and vacuum_sorted's columnar check removed. Three shell changes, each measured red first: - "index point lookup after sort" set only enable_seqscan off. With the reindex removed, so the index points at the old row numbers, it stayed green: it never read the index. The lookups now turn the custom scan off, with a premise each that they read t_col_id_idx (an Index Scan or, for the count, an Index Only Scan). - "reject non-columnar table" counted any error. With vacuum_sorted's columnar check removed, the heap table still raised -- XX001, reading the heap's file as columnar storage -- and the arm stayed green. Each refusal now requires its own SQLSTATE (42809, 42703, 22023, 42883). - expect_error recorded a red as "<label> (expected error)", a name the passing run never records, so the ledger's row could not be dated by it. It records under the label. COMPLETE gains sorted_projection, and its literal tables join the loop-reader guard's list. TESTS.md section 174, cluster_tests 744 -> 747. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… vacuum_sorted mutations (#1341) The suite had no rows. suites_not_covered 192 -> 191; census 4377 rows / 3053 never / 1324 dated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"add-column index scan" and "create index rows indexed once" forced their index with enable_seqscan off alone, which leaves the columnar custom scan on, and left bitmap scans on (which would also collapse a duplicate index entry). Both lookups now turn off the custom scan and bitmap scans, and each asserts an Index Scan or Index Only Scan through its index. Red first, with the index build handing every row to its callback twice: the old suite's "add-column index scan" stayed green, because it was not reading ac_c_idx. It is red now. "create index rows indexed once" was already red under it (its plan happened to read the index), and now its plan is asserted. audit has no ledger rows and no pytest twin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
test_native_ios.py carries all 11 checks by the shell's name in two tests, with the custom scan, seqscan and bitmap scans off for the database as the shell sets them. Under each of four mutations the twin reddens exactly the shell's set of checks: a delete not clearing the VM bit, VACUUM setting no VM bits, VACUUM not recording relallvisible, and relallvisible overshooting the relation by a synthetic block count (the unit error the #507 comment names). COMPLETE gains native_ios. TESTS.md section 175, cluster_tests 747 -> 749. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ity-map mutations (#1341) The suite had no rows. suites_not_covered 191 -> 190; census 4388 rows / 3058 never / 1330 dated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
jdatcmd
approved these changes
Oct 16, 2026
jdatcmd
left a comment
jdatcmd
left a comment
Collaborator
There was a problem hiding this comment.
Approve, at ce57934 (its own commits, on #1507). The twin matches the shell one for one, and both stay green under the two mutants below, so parity holds. Two gaps in the suite itself are on main already, so they're not this PR's to fix.
1. VACUUM after a delete is never exercised. My mutant: PgColumnarComputeAllVisibleGroups ignores the delete vector (if (false && hasDelete) continue;). A group with deleted rows then counts as all-visible, and a VACUUM marks its blocks visible, so an index-only scan skips the liveness check for its deleted rows. Both twins stay 11/11 green. The suite's order is VACUUM, then DELETE, then IOS, which is why your clear-on-delete mutant is caught and this one isn't. Fix: add a VACUUM after the DELETE, then the same after-delete oracle, so a block holding a deleted row must stay not-all-visible.
2. Rounding at a run's edge is not reachable. A second mutant rounds a visible run's first block down instead of up (b = lo / K), and both twins also stay green. This fixture's visible runs start on block boundaries, so a partly covered block never arises. It's lower priority; it needs a run that starts mid-block.
I'll take both as a follow-up on #1341 unless you want them. Your observation about relallvisible coming from the row runs, not the VM bits, is a third angle on the same code.
Collaborator
|
@OffgridwithJD, merging #1508 now: approved at ce57934, 15/15 green, CLEAN. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@jdatcmd The next twin-less suite,
native_ios. Stacked on #1507 (#1506 → #1507 → this). This PR's own commits are the top two.native_ios.shalready turns the custom scan off for its database, so it isn't in the #1339 class. This is a straight twin.The twin, name for name
All 11 checks by the shell's name, in two tests, with the same database-level settings. Under each of four mutations, the twin reddens exactly the shell's set:
PgColumnarVMClearForRow)PgColumnarVMSetVisible)relallvisiblerelallvisibleovershootsrelpagesby the synthetic block count (the unit error the #507 comment names)One observation: with no VM bits set at all, "VACUUM records the all-visible pages in pg_class (#507)" stays green.
relallvisibleis computed from the all-visible row runs, not from the bits the VM fork holds. The zero-fetch arm catches that mutant, so the suite as a whole isn't blind to it.Five-major runs at head: 11/11 for the shell and 11/11 for the twin, on each of 15–19.
Ledger
Census 4388 / 3058 never / 1330 dated (on #1506's 4377 / 3053 / 1324; #1507 changes no ledger rows), with suites_not_covered 191 → 190. 6 of the 11 checks are dated. The gate gives rc 0. Collection gives
cluster_tests 747 -> 749, and TESTS.md gets §175. The grader passes 40/40 and the guards 438/438.🤖 Generated with Claude Code