On Thu, Dec 29, 2022 at 12:00 PM Andres Freund <and...@anarazel.de> wrote: > > I could just move the same tests from heap_prepare_freeze_tuple() to > > heap_freeze_execute_prepared(), without changing any of the details. > > That might work, yes.
Attached patch shows how that could work. > It seems somewhat wrong that we discard all the work that > heap_prepare_freeze_tuple() did. Yes, we force freezing to actually happen in > a bunch of important cases (e.g. creating a new multixact), but even so, > e.g. GetMultiXactIdMembers() is awfully expensive to do for nought. Nor is > just creating the freeze plan free. I'm not sure what you mean by that. I believe that the page-level freezing changes do not allow FreezeMultiXactId() to call GetMultiXactIdMembers() any more often than before. Are you concerned about a regression, or something more general than that? The only case that we *don't* force xmax freezing in FreezeMultiXactId() is the FRM_NOOP case. Note in particular that we will reliably force freezing for any Multi < OldestMxact (not < MultiXactCutoff). > I wonder how often it'd be worthwhile to also do opportunistic freezing during > lazy_vacuum_heap_page(), given that we already will WAL log (and often issue > an FPI). Yeah, we don't actually need a cleanup lock for that. It might also make sense to teach lazy_scan_prune() to anticipate what will happen later on, in lazy_vacuum_heap_page(), so that it can freeze based on the same observation about the cost. (It already does a certain amount of this kind of thing, in fact.) -- Peter Geoghegan
v2-0001-Check-xmin-xmax-commit-status-when-freezing-execu.patch
Description: Binary data
