On Fri, Jul 28, 2023 at 3:00 PM Peter Geoghegan <p...@bowt.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
