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

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Takeshi Ideriha <iderihatakeshi(at)gmail(dot)com>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction
Date: 2026-10-21 01:20:18
Message-ID: CAGRkXqStu17-_568HNTqz_Qh7=FKTaRO2A572hizQuhMBbExvQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Michael,

>> Isn't heapam_relation_copy_for_cluster() the bit actually
>> incorrect here, marking the tuple with "isdead" to start with?

Thanks for looking at this so closely. You are right that the recheck
broke the contract of rewriteheap.c.

> Looking a bit more at that before the end of the day, I think that
> the suggestion of touching HeapTupleSatisfiesVacuumHorizon() and
> setting some hint bits would be the correct thing to do.

Agreed, and thanks for pointing at both places. v2 does just that and
leaves rewriteheap.c alone.

With the hint set, the old version no longer waits in unresolved_tups,
so the logical mapping change from v1 is not needed anymore.

Thanks,
Shihao

Attachment Content-Type Size
v2-0002-Add-a-test-for-CLUSTER-with-an-aborted-update.patch application/octet-stream 3.9 KB
v2-0001-Set-HEAP_XMAX_INVALID-for-aborted-updates-of-in-p.patch application/octet-stream 2.2 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2026-10-21 02:39:43 Re: BUG #19644: byteaout, float8out and float4out are marked IMMUTABLE but depend on GUCs
Previous Message shihao zhong 2026-10-21 00:45:45 Re: GIN jsonb_ops misses root strings in strict jsonpath queries