On Fri, Dec 30, 2022 at 12:43 PM Jeff Davis <pg...@j-davis.com> wrote: > I always understood "freezing" to mean that a concrete action was > taken, and associated WAL generated.
"When I use a word… it means just what I choose it to mean -- neither more nor less". I have also always understood freezing that way too. In fact, I still do understand it that way -- I don't think that it has been undermined by any of this. I've just invented this esoteric concept of nominal freezing that can be ignored approximately all the time, to solve one narrow problem that needed to be solved, that isn't that interesting anywhere else. > "Nominal freezing" is happening when there are no freeze plans at all. > I get that it's to manage control flow so that the right thing happens > later. But I think it should be defined in terms of what state the page > is in so that we know that following a given path is valid. Defining > "nominal freezing" as a case where there are no freeze plans is just > confusing to me. What would you prefer? The state that the page is in is not something that I want to draw much attention to, because it's confusing in a way that mostly isn't worth talking about. When we do nominal freezing, we don't necessarily go on to set the page all-frozen. In fact, it's not particularly likely that that will end up happening! Bear in mind that the exact definition of "freeze the page" is somewhat creative, even without bringing nominal freezing into it. It just has to be in order to support the requirements we have for MultiXacts (in particular for FRM_NOOP processing). The new concepts don't quite map directly on to the old ones. At the same time, it really is very often the case that "freezing the page" will perform maximally aggressive freezing, in the sense that it does precisely what a VACUUM FREEZE would do given the same page (in any Postgres version). -- Peter Geoghegan
