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

Hi

On 2026/10/22 11:22, Michael Paquier wrote:
> On Wed, Oct 21, 2026 at 06:01:28PM +0800, Zhijie Hou wrote:
>> + if (!(tuple->t_infomask & HEAP_XMAX_INVALID) &&
>> + !HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask) &&
>> + !HeapTupleHeaderIsOnlyLocked(tuple))
>> + {
>> + TransactionId xmax = HeapTupleHeaderGetUpdateXid(tuple);
>> +
>> + if (!TransactionIdIsInProgress(xmax) &&
>> + !TransactionIdDidCommit(xmax))
>> + SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
>> + InvalidTransactionId);
>>
>> If a tuple's Xmax is a MultiXact and the updating subtransaction is still in
>> progress when HeapTupleHeaderIsOnlyLocked() is called, it returns false.
>> However, if that updating subtransaction aborts before the second
>> TransactionIdIsInProgress() check, the second check returns false and sets
>> HEAP_XMAX_INVALID on the tuple even though the MultiXact still has active
>> members, which I think violates the MultiXact hint-bit standard.
>
> Perhaps also check for HEAP_XMAX_IS_MULTI to skip the multixacts and
> make sure that active members are not lost, then? I am not completely
> sure if this would be always right, though, these code paths are the
> hard-level definition of tricky.
>
I'm +1 for fixing the subtransaction issue first but let me add a
comment regarding this multixact race issue.

It should be OK not to set the hint bit for a tuple whose xmax is
MultiXact containing a key locker and an aborted updating
subtransaction. This is because rewrite_heap_tuple filters out this
tuple by HeapTupleHeaderIsOnlyLocked and doesn't put it into unresolved
table. I'm not sure if there is another issue we need to consider in
addition to the performance issue.

Regards,
Takeshi Ideriha