ttl_expire has no pytest twin, and it is the suite for the one function that deletes rows

[jdatcmd]

test/ttl_expire.sh has no pytest counterpart, so the pair does not exist and appears in neither COMPLETE nor INCOMPLETE in test_compare_to_bash.py.

Why this is a gap rather than a choice

The twin rule exists because the two harnesses fail differently. ttl_expire is the suite for pgcolumnar.expire, which deletes rows, and it is the one place in the tree where a wrong answer destroys data rather than reporting a wrong number. It is a poor candidate for single-harness coverage.

It was noticed while fixing #1135 (a date retention column). That change added arms to the shell suite only, deliberately and with the reason stated in the PR: a partial test_ttl_expire.py would manufacture a pair that cannot reach zero MISSING against a 43-check shell suite, landing it in INCOMPLETE -- a declared gap about the port, filed inside a change about a date type. #1183 had just emptied INCOMPLETE, and reopening it for an unrelated reason is worse than the gap it would record.

What the port owes

ttl_expire.sh is 43 checks at 3363331. The port must assert every one of those names for the pair to enter COMPLETE, which is the standing arm's rule.

The properties, in the order the shell suite establishes them:

1. A group whose rows are all past the retention is retired.
2. A group that straddles the cutoff survives with every row. This is the one that matters: dropping it is data loss, and a suite that only proved expired data disappears would pass on an implementation that dropped everything.
3. A group holding NULL retention values is not retired, because the zone map's maximum covers only non-NULL values.
4. An all-visible group is retired correctly, because expire bypasses the delete vector and the visibility-map bits VACUUM set stay on.
5. A table with no declared retention raises an error rather than reporting that it did nothing.
6. A second run retires nothing.
7. The date column arms from opt: pgcolumnar.expire refuses a date retention column, though date is handled everywhere else #1135, including the rounding: a row dated exactly on the cutoff is kept.

What to watch when porting

• The shell fixture pins pgcolumnar.stripe_row_limit=1000 in the cluster config rather than with SET, so the writing session and every later session agree about the geometry (The cost model reads the session's stripe_row_limit, not the geometry the table was written with #806). A port that sets it per-session gets a different layout and the straddling group stops straddling.
• The rounding arm in 7 is only discriminating because the fixture puts 1,000 rows exactly on the cutoff day and the cutoff carries a time of day. An arm that compares midnight with midnight returns the same answer whichever way the rounding goes, which was measured during opt: pgcolumnar.expire refuses a date retention column, though date is handled everywhere else #1135 and is an easy thing to port into uselessly.

Done when

ttl_expire is in COMPLETE with zero MISSING, and INCOMPLETE is still {}.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XiFn3HteTXnGdRiA2xDP2n

[jdatcmd]

Two corrections to this issue, both to numbers I wrote, and one of them makes the acceptance clause unsatisfiable.

The suite is not 43 checks

43 checks at 3363331 is stale. #1187 landed after that sha and added the date arms and the timezone loop. Measured on main at 3519856e, three layers that give three different numbers:

layer	count	how
^check " at column 0	43	the number in this issue
call sites anywhere	47	four more, indented inside the $_tz loop
runtime check names	51	ttl_expire.sh prints checks run: 51

@OffgridwithJD measured 47 and 51 independently and reached the same place.

I produced the stale 43 the same way the issue did: grep -cE '^check "', anchored at column 0, which cannot see a call inside a for body. That is the command-position miss this repository already has a note about, and it read as a plausible total because 43 is a plausible total.

The tool's own line is the instrument. checks run: 51, printed by the suite, settles it without an extractor.

What the grader actually requires, which is a fourth number

compare_to_bash.py reads 47 names from the shell suite and keeps the four zone ones uninterpolated:

premise: in $_tz the fixture straddles that session's cutoff
premise: one date per row group in $_tz, so no group straddles the cutoff
expire in $_tz keeps exactly the rows at or after that session's cutoff
and no row older than $_tz's own cutoff survives

It matches literally first, then by template: _template() reduces $_tz and {tz} alike to {}. So the port satisfies those four with an f-string over a loop variable, and does not need to name UTC and Pacific/Midway literally. The port's own loop still has to cover the same zones for the arms to be about the same thing, but the grader is matching shapes there, not strings.

So: 51 properties to assert, 47 names to match, four of them templated.

The "Done when" clause is unsatisfiable as written

ttl_expire is in COMPLETE with zero MISSING, and INCOMPLETE is still {}.

#1196 merged and put range_pruning in INCOMPLETE with its reason, so INCOMPLETE is not {} any more and cannot be made so by this work. A merged PR falsified a line in an issue it does not touch, which is the same shape as the docs/limitations.md paragraph #1196 falsified and #1200 repaired, one level up. Neither of us would have noticed until the acceptance check failed.

Reading it as intended:

ttl_expire is in COMPLETE with zero MISSING, and INCOMPLETE gains no new entry.

The third trap, which the issue does not name

The two traps listed are real. There is a third and it is invisible from the source: the port's timezone list must match the shell's, because the zone is interpolated into the check name. A port that loops over different zones asserts every property correctly and still cannot reach zero MISSING, because the template positions line up and the concrete arms are about a different pair of zones.

On the fixture geometry

The shell bakes pgcolumnar.stripe_row_limit=1000 into the cluster config before the postmaster starts. The pytest corpus has an established, better answer for a port: per-table pgcolumnar.set_options(..., stripe_row_limit => 1000) with a premise asserting the resulting group count, which test_hilbert_cluster.py already does (premise: set_options took, so s2c is 20 groups and not one). 1000 is exactly set_options' floor, so it is legal, and a refusal there prints and does not abort -- so the premise is what makes it visible rather than optional.