| 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-05-30 22:10:11 |
| Message-ID: | CAH2-WznOen7eL_Gx1nBGkvCVP+45FshTw-vmUXWYTJJQ=uRy4A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 30, 2025 at 5:57 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> I don't see how OldestXmin comes into play with the visibility_cutoff_xid.
Code in heap_page_is_all_visible() (and other place, I guess the other
one is in pruneheap.c now) have a separate OldestXmin test:
/*
* The inserter definitely committed. But is it old enough
* that everyone sees it as committed?
*/
xmin = HeapTupleHeaderGetXmin(tuple.t_data);
if (!TransactionIdPrecedes(xmin,
vacrel->cutoffs.OldestXmin))
{
all_visible = false;
*all_frozen = false;
break;
}
Once we "break" here, it doesn't matter what visibility_cutoff_xid has
been set to. It cannot be used for any purpose.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-05-30 22:22:15 | Re: Correcting freeze conflict horizon calculation |
| Previous Message | Melanie Plageman | 2025-05-30 21:56:50 | Re: Correcting freeze conflict horizon calculation |