native_cancel: the interrupt-correctness half is lost in CI, and it is the half that matters

[jdatcmd]

Follow-up from the #236 review, raised by @ChronicallyJD and verified.

The problem

PGC_SKIP_TIMING=1 drops three suites in CI, which is right for the wall-clock
ratio suites. But native_cancel.sh is not purely a ratio suite. It contains two
checks of different kinds:

native_cancel.sh:62   check "the short timeout is what fired"
                      asserts the error is "canceling statement due to statement timeout"
                      -> a CORRECTNESS property: the interrupt was honoured

native_cancel.sh:68   check "cancel arrives well before the load completes"
                      asserts cancel < full / 2
                      -> a RATIO, which is why the suite is skipped

Skipping the whole suite means CI would not catch a regression that removes
CHECK_FOR_INTERRUPTS from the decode path. After such a regression
statement_timeout, pg_cancel_backend() and standby recovery-conflict
resolution would all hang, and every remaining CI check would stay green.

That is not hypothetical for this codebase: three interrupt floors have been
added in the last two days (#220 columnar_fetch_row, #231 the buffered walk,
and the guard in ColumnarThriftSkip), each because a loop had none. The class
recurs.

Why it cannot simply be un-skipped

The correctness check at :62 is still timing-shaped: the 50 ms
statement_timeout only fires if the load outlasts it. On a fast runner the load
can finish first, no timeout fires, and the check fails for reasons unrelated to
interrupt handling. Un-skipping as-is trades a coverage gap for a flaky gate,
which is the trade this project keeps refusing.

What to build

A CI-safe interrupt-correctness check with no ratio in it:

• start a long columnar scan,
• cancel it from another session with pg_cancel_backend() (or a generous
  statement_timeout, seconds not milliseconds),
• assert it ERRORs with canceling statement due to ... within a generous bound,
• assert the backend is still alive and the cluster is usable afterwards.

That asserts the interrupt was honoured without asserting how long anything took,
so it is safe on shared hardware and can run in CI unconditionally. The existing
ratio check stays where it is, local-only.

Acceptance: the new check runs in CI (not under PGC_SKIP_TIMING), and removing
a CHECK_FOR_INTERRUPTS from the decode path turns it red. Prove it by removal,
or it is not known to work.

[jdatcmd]

I set out to implement this and found the premise does not hold. Reporting that
before doing the work, because the work would not have delivered what the issue
asks for.

The claim

Skipping the whole suite means CI would not catch a regression that removes
CHECK_FOR_INTERRUPTS from the decode path.

That is true of CI. It is also true of the suite. native_cancel does not catch
that regression either, in either of its two checks.

Proved by removal

I removed all four CHECK_FOR_INTERRUPTS calls from src/columnar_reader.c, the
decode path the suite exercises, rebuilt, and ran it:

-- full load 198 ms; cancel fired after 65 ms
PASS  the short timeout is what fired
PASS  cancel arrives well before the load completes
native_cancel.sh: PASSED

Both assertions pass with the interrupt checks gone. The correctness check passes
because the timeout still fires and still produces
canceling statement due to statement timeout. The ratio passes because the
cancel still arrives at 65 ms against a 198 ms baseline.

Something else services the interrupt during that query, so the columnar checks
are not what makes the timeout land early in this fixture.

I also spent a run proving the wrong thing first: I removed the check in
columnar_write_state.c, because I assumed the "load" the suite times was the
insert. It is not. Line 55 times SELECT * FROM cancel_t LIMIT 1, so the suite
exercises decode, not write. Worth stating because the suite's own output says
"full load", which is what led me there.

What that means for this issue

Running the correctness half in CI, which is what this asks for, would add a check
that passes whether or not the property holds. That is the shape this project
keeps finding and removing, most recently three cache assertions that passed
against a cache with no callers.

So the ordering has to be: make the suite able to fail first, then decide
where it runs. A fixture where the decode genuinely dominates and no core
interrupt check intervenes, with an assertion that reds when the columnar checks
go. Until that exists, moving the suite into CI buys nothing.

What I have landed instead

A separate defect this uncovered. native_fetch_cache holds a wall-clock ratio
and is not classified as a timing suite, so CI runs it and it flakes:

FAIL  fetching from one big group is not far dearer than from ten small ones:
      got [no (one=397ms ten=91ms)]

It failed a PR of mine for reasons unrelated to the change, which is the exact
harm PGC_SKIP_TIMING exists to prevent.

check_timing in lib.sh skips a single ratio assertion under
PGC_SKIP_TIMING while the rest of the suite runs, announcing the skip rather
than counting it as a pass. That is the mechanism this issue wanted, applied
where it does some good. native_cancel uses it too, and stays out of CI for now,
so that when someone makes the suite detect something it is one line to move.

Leaving this open, retitled in effect: the suite needs to be able to fail before
where it runs matters.