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

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Zhijie Hou <houzhijie22(at)gmail(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com>, 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-26 23:43:22
Message-ID: 179305820270.2778603.17090680794615137662@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Michael,

On Tue, Oct 27, 2026 at 08:34:41AM +0900, Michael Paquier wrote:
> Piling workarounds on top of workarounds is no good for these code
> paths. They just become more complicated to think about long-term.

Fair enough. The patch grew by adding each condition as it came up in
the thread, not from a clear account of when that hint is safe to
set, and Zhijie's race shows how fragile that is. I'll withdraw it.
Your commit fixes the reported case. If I come back to the second
spot, it will start from that account, not from another variant.

Manu

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Chris St Denis 2026-10-27 02:54:40 crash in ltree_compare_distance() in 14.24
Previous Message Michael Paquier 2026-10-26 23:34:41 Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction