| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Correcting freeze conflict horizon calculation |
| Date: | 2026-03-10 16:53:42 |
| Message-ID: | CAH2-WzkrqYvLGVo8pkjZjdcv9PitWNYXr1b1RALtDv=f=womiw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 10, 2026 at 12:12 PM Melanie Plageman
<melanieplageman(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2026-03-10 16:54:12 | Re: Potential security risk associated with function call |
| Previous Message | Jacob Champion | 2026-03-10 16:43:27 | Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode |