Re: REPACK enhancements

Hi Antonin,

On Tue, Nov 10, 2026 at 11:54 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> For now I commented the assertion out and added a comment on possible
> solutions.

Leaving it out looks safe to me, and the check can stay. Every other
caller passes GetCurrentTransactionId(), and in all the runs I made
(UPDATE, DELETE, savepoints, TOAST, row lockers, 150 replayed calls)
the replay reached the function with xmax still zero: the copy clears
it and only REPACK writes to the new heap. So the attached assertion
keeps the old check and states what REPACK relies on; it passes
Shihao's spec and the existing REPACK tests. With assertions off, a
REPEATABLE READ snapshot taken while REPACK waited for the lock saw the
same rows as an untouched copy of the table in every one of those runs.

A correction: in September I blamed the transient heap's XID, but that
run had failed before the final lock. Shihao has it right.

Regards,
Manu