Re: Allow aggressive VACUUM to freeze without a cleanup lock

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Jingtang Zhang <mrdrivingduck(at)gmail(dot)com>
Cc: Yuhang Qiu <iamqyh(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Allow aggressive VACUUM to freeze without a cleanup lock
Date: 2026-08-26 18:43:34
Message-ID: CAAKRu_ak7zXnFcH8czhG93M7AUiy0FUA3HBRpzzqCm6PLa4=zQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 26, 2026 at 1:27 PM Jingtang Zhang <mrdrivingduck(at)gmail(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bryan Green 2026-08-26 18:44:58 Re: Fire create_upper_paths_hook for UPPERREL_PARTIAL_GROUP_AGG
Previous Message Andrey Borodin 2026-08-26 18:28:51 Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin