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