On Tue, Aug 25, 2026 at 10:28 AM Peter Geoghegan <[email protected]> wrote: > As far as I know, the only fundamental reason we require a cleanup > lock is to make page defragmentation safe. Pruning as currently > defined implies page defragmentation, and freezing is closely tied to > pruning, so we tend to treat both as requiring a cleanup lock. But a > cleanup lock is likely not strictly necessary.
Fun fact: prior to the invention of HOT in 2007, we'd freeze with only a *shared* lock in the first heap pass. The first heap pass collected dead TIDs and performed freezing, but it didn't do any pruning. Freezing wasn't tied to pruning (or anything like it) in the way it is today. Pruning didn't really exist (not as we know it today), but page defragmentation did. At that time, we only removed dead tuples/tuple storage and performed page defragmentation in VACUUM's second heap pass (which required a full cleanup lock). So it's reasonable to surmise that freezing could be done with only an exclusive lock on top of the current VACUUM code (though not a shared lock, which seems really dangerous). And that page defragmentation is the only thing that necessitates a cleanup lock/makes this idea difficult. -- Peter Geoghegan
