On Wed, Aug 26, 2026 at 1:27 PM Jingtang Zhang <[email protected]> wrote: > > > There is also a small naming issue. lazy_scan_noprune and lazy_scan_freeze > > are > > quite confusing now. I think lazy_scan_noprune is not correct at this > > moment. > > The current names describe three different paths: lazy_scan_prune() > does pruning and freezing, lazy_scan_freeze() does freezing only, and > lazy_scan_noprune() does neither. The last name predates this patch, > but I agree that it is less clear now.
I don't have time to pick up moving this project forward right now, but after a quick glance at the patches, I wouldn't structure the code the way you have it. I think what you'll want is some kind of refactor of lazy_scan_new_or_empty() (which already escalates to an exclusive lock for empty pages) and of lazy_scan_noprune(). This is already a pretty complicated set of states and adding a new one where we hold a different lock type and want to do a different subset of tasks and based on various things may want to then do a different set of tasks (i.e. go try to get the cleanup lock again if there are old enough dead tuples but only if it was an aggressive vacuum which was checked elsewhere, etc) without more refactoring of the existing code seems to confusing to me. Do you know if in your use case this would have been able to do the freeze (i.e. you didn't have too-old dead tuples on the page) with needing pruning? - Melanie
