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

Hi,

On Fri, Oct 23, 2026 at 7:42 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Oct 22, 2026 at 04:53:41PM +0800, Zhijie Hou wrote:
> > +1 to fix that part first. That part of the fix (patch) looks clean to me. It
> > also covers more common cases, which can happen for both user tables and
> > catalogs, while the other part (the complicated, performance-sensitive one) only
> > covers catalog cases IIUC, as user table DML holds locks until transaction end,
> > so concurrent CLUSTER can't touch it in that case.
>
> Please find attached a patch to do this part, for now.
>
> > One idea to improve is to do these expensive checks only when xmin is not equal
> > to xmax. If xmin is still in progress, xmax cannot be aborted, so it's safe to
> > return early in that case. The DELETE test wouldn't regress after this change,
> > since xmin and xmax differ there. The subxact_update test would still regress,
> > but that's likely a rare case.
>
> Yeah, the xmin <> xmax check would make sense here. I'd like to
> suspect that you should be able to make back for most of the
> performance regression of v2 with tweaks like that.
>
> How does the attached look to you?

Thanks for updating the patch, it looks good to me.

Best Regards,
Zhijie Hou