Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction

Hi Michael,

On Mon, Oct 26, 2026 at 09:57:20AM +0900, Michael Paquier wrote:
> Thanks for the reviews. Applied and backpatched this part down to
> v14.

Thanks for taking care of it. The attached series adds the second
spot on top of e7f4463e869, as shihao asked upthread.

0001 sets HEAP_XMAX_INVALID in the branch of
HeapTupleSatisfiesVacuumHorizon() where the inserter is another
backend that is still running, once the updater has aborted. It
skips xmax == xmin and MultiXacts, and it asks the clog first and
then the proc array, so it does not open the window Zhijie found in
my clog-only version. It includes shihao's isolation spec, which
loses the pg_class row without the fix. 0002 is Zhijie's test for
that window.

VACUUM with your scripts, 64 holders, one run of 12 interleaved
rounds on 2026-10-25, ratios to HEAD:

delete.sql: 1.00x
subxact_updates.sql: 1.00x (with v2's check: 1.51x)
aborted updates, first VACUUM: 1.07x, same as v2's check
aborted updates, following VACUUMs: 1.00x

"Aborted updates" is a new script where each subtransaction rolls
back after its UPDATE. It is the only case where 0001 asks the proc
array, once per tuple, in the VACUUM that sets the hint. The
measured heapam_visibility.c matches 0001 except for two lines of a
test overlay. Method and the script are in measurements.txt.

0001 and 0002 apply with git am on master and REL_19_STABLE. On 14
to 18 the code applies as is, but the isolation_schedule line needs
another neighbor. 0002 only goes down to 17, where the injection
points it uses exist. I ran make check and the isolation and
injection_points suites on master and 19, and make check and
isolation on 14.

The xmin != xmax check and the race are Zhijie's, the MultiXact skip
is yours, and the spec is shihao's.

Regards,
Manu