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
-
Use the newest to-be-frozen xid as the conflict horizon for freezing
- c2a23dcf9e3a 19 (unreleased) landed
-
Avoid hot standby cancels from VAC FREEZE
- 66fbcb0d2e1b 9.5.0 cited