Allow aggressive VACUUM to freeze without a cleanup lock

On Tue, Aug 25, 2026 at 6:32 AM Jingtang Zhang <mrdrivingduck@gmail.com> wrote:

The 2011 discussion [2] raised the related question of whether VACUUM
could make progress after failing to acquire a cleanup lock. It found that
changing line pointers while holding only an exclusive buffer content lock
would be unsafe, because another backend can inspect a line pointer while
holding only a buffer pin. However, freezing tuple headers is different: an
exclusive buffer content lock is sufficient for that.

I think this proposal (in the email) should explain why freezing xids
and mxids is safe with only an exclusive lock. AFAICT that 2011 thread
doesn't get specific. And today, lazy_scan_noprune() specifically
returns false and requires a cleanup lock during an aggressive vacuum
when freezing would be required. If this is not necessary, you should
explain why. Was it never required and we were being over-cautious?
Did something change in the code to make it safe and we forgot to
update lazy_scan_noprune()?

- Melanie

On Tue, Aug 25, 2026 at 10:06 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:

I think this proposal (in the email) should explain why freezing xids
and mxids is safe with only an exclusive lock. AFAICT that 2011 thread
doesn't get specific.

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.

Freezing expects pruning to remove dead tuples, because we have no way
to freeze them. But it doesn't actually require page defragmentation.
So it is probably possible to invent a variant of pruning that doesn't
remove tuple storage, and thus has no need to defragment the page. I'm
thinking of an approach that performs an in-place update of xmin and
xmax, setting both to InvalidTransactionId. That would enable
repurposing lazy_scan_noprune into (say) lazy_scan_nodefrag, which
would always be able to freeze (and psuedo-prune) every page without
waiting for a cleanup lock.

Obviously I haven't prototyped this, so there might be some hard to
foresee difficulties. It's possible that pruning relies on cleanup
locks in a way nobody realizes right now -- it wouldn't be the first
time something like that happened. When I made the second pass over
the heap not require a cleanup lock for Postgres 14, it exposed race
conditions with how we set the visibility map in that pass.
Technically that wasn't my fault; the fixes for those bugs were in and
around heap_update IIRC.

--
Peter Geoghegan

On Tue, Aug 25, 2026 at 10:28 AM Peter Geoghegan <pg@bowt.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

Hi Melanie, Peter, Jingtang,

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.

Agreed. Freezing itself only needs an exclusive lock, a cleanup lock is needed
for page defragmentation. I also agree with Melanie that the patch should
explain this if it is not already documented elsewhere.

I reviewed the patch and found a few issues.

First, the buffer lock is released and reacquired between
`lazy_scan_noprune()` and `lazy_scan_freeze()`. The page may be changed or
already frozen during this window, so this assertion is not always valid:
```C
Assert(state.pagefrz.freeze_required);
```

Second, the code may call heap_prepare_freeze_tuple() and then discard the
freeze plans after finding an old DEAD tuple. This function may create a new
MultiXactId, write WAL, and advance the MultiXact state. These side effects
remain even if the plans are discarded.

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 patch adds FreezeState, HeapPageFreezeParams, and
HeapPageFreezeResult, but they overlap with PruneState,
PruneFreezeParams, and PruneFreezeResult. These abstractions add complexity
without much reuse.

Pages containing old XIDs or MultiXactIds in DEAD tuples still need a cleanup
lock. I think this is a reasonable limitation for this patch.

Best Regards,
Yuhang Qiu