Re: Correcting freeze conflict horizon calculation

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2026-03-10T16:53:42Z
Lists: pgsql-hackers
On Tue, Mar 10, 2026 at 12:12 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I've taken a stab at distilling down the comment and put it above
> heap_prepare_freeze_tuple(). This is what I came up with:
>
>  * FreezePageConflictXid is advanced only for xmin/xvac freezing, not for xmax
>  * changes. We only remove xmax state here when it is lock-only, or when the
>  * updater XID (including an updater member of a MultiXact) must be aborted;
>  * otherwise, the tuple would already be removable. Neither case affects
>  * visibility on a standby.
>
> I don't mention why we need a conflict horizon when freezing there,
> but I do in the comment above the struct member:

> Do these seem correct enough and understandable?

Yes. This LGTM.


-- 
Peter Geoghegan



Commits

  1. Use the newest to-be-frozen xid as the conflict horizon for freezing

  2. Avoid hot standby cancels from VAC FREEZE