Re: Handle concurrent drop when doing whole database vacuum

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: 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>, suryapoondla4 <suryapoondla4(at)gmail(dot)com>
Subject: Re: Handle concurrent drop when doing whole database vacuum
Date: 2026-06-27 02:09:57
Message-ID: aj8w9b4OOBzyFkhx@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 26, 2026 at 02:19:37PM -0700, Bharath Rupireddy wrote:
> I had a quick look at the repack code and it seems like it can also
> run into the same problem because repack_is_permitted_for_relation
> uses the same pg_class_aclcheck while building the tables list without
> holding locks, and later it rechecks permissions after the table locks
> in cluster_rel_recheck anyway. A simple fix there would be to just use
> pg_class_aclcheck_ext in repack_is_permitted_for_relation. I recommend
> discussing this in a separate thread CC-ing the repack authors to get
> agreement.

A separate would be appropriate, yes. For the repack part, there may
be an argument for tweaking the behavior (or not). The vacuum part
dates back to 2018, and is much older.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-06-27 02:33:24 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Feng Wu 2026-06-27 02:08:59 [PATCH] Avoid collation lookup for "char" statistics