Re: Handle concurrent drop when doing whole database vacuum

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: "nathandbossart(at)gmail(dot)com" <nathandbossart(at)gmail(dot)com>, cca5507 <cca5507(at)qq(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "pgsql(at)j-davis(dot)com" <pgsql(at)j-davis(dot)com>
Subject: Re: Handle concurrent drop when doing whole database vacuum
Date: 2026-06-30 23:35:12
Message-ID: akRSsP3NBe0tvKRI@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

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