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: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Allow aggressive VACUUM to freeze without a cleanup lock
Date: 2026-08-25 14:06:24
Message-ID: CAAKRu_Z+ROEiBs3odEHbqatTs5Bk9TUdbmCXnveBScss-GEDng@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 25, 2026 at 6:32 AM Jingtang Zhang <mrdrivingduck(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2026-08-25 14:06:57 Re: Replace px_memset() with explicit_bzero()
Previous Message Antonin Houska 2026-08-25 13:59:03 Re: Tracking per-RelOptInfo uniqueness during planning