From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
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:22:15 |
Message-ID: | CAAKRu_bFSzMuO_cVp4NSCt-Eeckb0Nyqpi7qNyP-QWZ5SQK7SQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 30, 2025 at 6:10 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> 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.
Ah, I see this is done before visibility_cutoff_xid is advanced, so
visibility_cutoff_xid won't end up ever being a value newer than
OldestXmin. So it's not really the newest committed xmin on the page,
it is the newest committed xmin on the page preceding OldestXmin. I
had always been thinking of it as the newest committed xmin on the
page.
- Melanie
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2025-05-30 22:38:32 | Re: Reduce DEBUG level of catcache refreshing messages |
Previous Message | Peter Geoghegan | 2025-05-30 22:10:11 | Re: Correcting freeze conflict horizon calculation |