On Wed, Dec 21, 2022 at 4:30 PM Jeff Davis <pg...@j-davis.com> wrote: > The confusing thing to me is perhaps just the name -- to me, > "freeze_required" suggests that if it were set to true, it would cause > freezing to happen. But as far as I can tell, it does not cause > freezing to happen, it causes some other things to happen that are > necessary when freezing happens (updating and using the right > trackers).
freeze_required is about what's required, which tells us nothing about what will happen when it's not required (could go either way, depending on how lazy_scan_prune feels about it). Setting freeze_required=true implies that heap_prepare_freeze_tuple has stopped doing maintenance of the "no freeze" trackers. When it sets freeze_required=true, it really *does* force freezing to happen, in every practical sense. This happens because lazy_scan_prune does what it's told to do when it's told that freezing is required. Because of course it does, why wouldn't it? So...I still don't get what you mean. Why would lazy_scan_prune ever break its contract with heap_prepare_freeze_tuple? And in what sense would you say that heap_prepare_freeze_tuple's setting freeze_required=true doesn't quite amount to "forcing freezing"? Are you worried about the possibility that lazy_scan_prune will decide to rebel at some point, and fail to honor its contract with heap_prepare_freeze_tuple? :-) > A minor point, no need to take action here. Perhaps rename the > variable. Andres was the one that suggested this name, actually. I initially just called it "freeze", but I think that Andres had it right. > I think 0001+0002 are about ready. Great. I plan on committing 0001 in the next few days. Committing 0002 might take a bit longer. Thanks -- Peter Geoghegan
