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

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?
--
Michael