Re: Handle concurrent drop when doing whole database vacuum - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Handle concurrent drop when doing whole database vacuum
Date
Msg-id akRSsP3NBe0tvKRI@paquier.xyz
Whole thread
In response to Re: Handle concurrent drop when doing whole database vacuum  (surya poondla <suryapoondla4@gmail.com>)
Responses Re: Handle concurrent drop when doing whole database vacuum
List pgsql-hackers
On Tue, Jun 30, 2026 at 04:03:14PM -0700, surya poondla wrote:
> v8 is a better landing than v6 (which I'd LGTM'd). Michael's repro made it
> clear that removing the early ACL filter would let
> an unprivileged VACUUM actually stack behind a privileged lock, which
> a556549 commit was preventing.
> v8 preserves that protection while handling the concurrent-drop in
> get_all_vacuum_rels, and feels like the right shape.

v8 is taking the right approach here.


> 3. The Assert that Bharath suggested earlier doesn't apply as-is but can be
> incorporated into the patch as:
> Assert(missing_ok || CheckRelationOidLockedByMe(relid, AccessShareLock,
> true));

This fail-safe would be a welcome addition, yes.  Perhaps Nathan feels
differently, which would be also fine by me.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions
Next
From: Michael Paquier
Date:
Subject: Re: WAL compression setting after PostgreSQL LZ4 default change