Re: Allow aggressive VACUUM to freeze without a cleanup lock

On Tue, Aug 25, 2026 at 10:28 AM Peter Geoghegan <pg(at)bowt(dot)ie> 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