| 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
| 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 |