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

The following bug has been logged on the website:

Bug reference: 19760
Logged by: Alperen Keles
Email address: alpkeles99(at)gmail(dot)com
PostgreSQL version: 18.6
Operating system: macOS 26 arm64 (also seen on Ubuntu 24.04 x86_64)
Description:

CLUSTER (and REPACK on master) silently drops a live row when the same
transaction inserted the row and then updated it inside a subtransaction
that was rolled back. No error is raised; the row is gone after COMMIT.

CREATE TABLE t1(c0 int, c1 int);
CREATE INDEX t1_i0 ON t1 (c1);
BEGIN;
INSERT INTO t1 VALUES (1, 1);
SAVEPOINT s1; UPDATE t1 SET c0 = 2; ROLLBACK TO s1;
CLUSTER t1 USING t1_i0;
SELECT count(*) FROM t1; -- 0, expected 1
COMMIT;
SELECT count(*) FROM t1; -- 0, expected 1

Reproduced with default settings on 18.6 (REL_18_STABLE a85b5523e67),
14.24 and master 158b6d5109 (all --enable-cassert --enable-debug, macOS
arm64); also found on master on Ubuntu x86_64. Rechecked on 2026-10-15
(Ubuntu 24.04, x86_64, gcc 13.3, --enable-cassert --enable-debug, server
under ulimit -v 6 GB):
the same on 19rc1 (REL_19_STABLE 0fb192f1b02), master aa7b9cf132b and
REL_18_STABLE 4d62ef92fda. CLUSTER VERBOSE reports a
negative "dead row versions cannot be removed yet" count (-1 here).

Found with a query fuzzer.