Re: Correcting freeze conflict horizon calculation

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: 2025-06-03 18:05:10
Message-ID: CAH2-WznZx2uYNe8pYKp2BGpiQJzKbVwcSsv6JO+hy53kri8xeA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 3, 2025 at 1:59 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> We do currently end up using OldestXmin-1 as our
> snapshotConflictHorizon when this happens, but as I said in the other
> email, I don't think that that's really required.

Actually, that's not really true, either. That is, it is possible
(though probably very rare) for VACUUM to set an xmax Multi >
OldestMxact with individual members that are still > OldestXmin, while
ultimately being able to set the page all-frozen in the VM.
snapshotConflictHorizon would then come from visibility_cutoff_xid --
which might end up being InvalidTransactionId.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-06-03 18:12:59 Re: ABI Compliance Checker GSoC Project
Previous Message Sami Imseih 2025-06-03 18:04:36 Re: Improve explicit cursor handling in pg_stat_statements