Re: Eager page freeze criteria clarification

On Fri, Jul 28, 2023 at 3:00 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > Or are we trying to determine how likely
> > the freeze record is to emit an FPI and avoid eager freezing when it
> > isn't worth the cost?
>
> No, that's not something that we're doing right now (we just talked
> about doing something like that). In 16 VACUUM just "makes the best
> out of a bad situation" when an FPI was already required during
> pruning. We have already "paid for the privilege" of writing some WAL
> for the page at that point, so it's reasonable to not squander a
> window of opportunity to avoid future FPIs in future VACUUM
> operations, by freezing early.

This doesn't make sense to me. It's true that if the pruning record
emitted an FPI, then the freezing record probably won't need to do so
either, unless by considerable ill-fortune the redo pointer was moved
in the tiny window between pruning and freezing. But isn't that also
true that if the pruning record *didn't* emit an FPI? In that case,
the pruning record wasn't the first WAL-logged modification to the
page during the then-current checkpoint cycle, and some earlier
modification already did it. But in that case also the freezing won't
need to emit a new FPI, except for the same identical case where the
redo pointer moves at just the wrong time.

Put differently, I can't see any reason to care whether pruning
emitted an FPI or not. Either way, it's very unlikely that freezing
needs to do so.

--
Robert Haas
EDB: http://www.enterprisedb.com