Re: Handle concurrent drop when doing whole database vacuum

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(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>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Handle concurrent drop when doing whole database vacuum
Date: 2026-06-29 16:54:44
Message-ID: akKjVNL9LyTexpEi@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 24, 2026 at 08:40:22AM +0900, Michael Paquier wrote:
> I'd sure welcome Nathan and Jeff opinions (added now in CC) regarding
> this line of thoughts; they worked on MAINTAIN, even if the early
> relation ACL check when building a list of relations for a
> database-wide manual VACUUM predates that.

I'm mostly concerned about reopening the ability for folks to take strong
locks on catalogs without the necessary privileges, even if they are only
briefly held. Commit a556549 fixed a real problem, so I'm nervous about
partially reverting it. IOW my first reaction is that v1 is the right
idea, i.e., we should just skip the relation if it disappears. I'm not
sure we even need to log it.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Diego 2026-06-29 17:14:12 [PATCH] - Re: libpq: decouple the .pgpass lookup port from the connection port
Previous Message Robert Haas 2026-06-29 16:30:47 Re: RFC: Logging plan of the running query