Re: vacuumdb: permission denied for schema "pg_temp_7"

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Michael Paquier <michael@paquier.xyz>, Christophe Pettus <xof@thebuild.com>, vaibhave postgres <postgresvaibhave@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, pgsql-bugs@lists.postgresql.org, vsekar@microsoft.com
Date: 2024-09-24T14:26:21Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. vacuumdb: Schema-qualify operator in catalog query's WHERE clause.

  2. reindexdb: Skip reindexing temporary tables and indexes.

  3. vacuumdb: Skip temporary tables in query to build list of relations

  4. Use catalog query to discover tables to process in vacuumdb

On Tue, Sep 24, 2024 at 11:20:43PM +0900, Fujii Masao wrote:
> On 2024/09/24 10:08, Michael Paquier wrote:
>> About the permission restrictions depending on the objects listed, the
>> filtering query uses currently a list of VALUES in a CTE.  Perhaps it
>> would be more elegant to switch that to a SELECT with some
>> has_schema_privilege() for the cases where OBJFILTER_SCHEMA is
>> used?
>> 
>> There permission checks with USAGE and MAINTAIN are broader, so I'd
>> choose to add a skip on the temp persistence first and backpatch it
>> down to 12 as there is also a performance argument.  Then tackle the
>> rest by reworking the VALUES part in the CTE.
> 
> Are you suggesting that any objects a user lacks sufficient privileges for
> should be silently excluded from vacuuming? This could make vacuumdb appear
> successful because no errors occur, but some tables the user intended to
> vacuum might be skipped without notice. That seems more problematic to me.

Yeah, this is what I mentioned upthread [0].  If the user doesn't specify
anything in --table or --schema, then it's probably fine to silently skip
objects for which they lack privileges.  But if they do explicitly specify
a table or schema that they cannot vacuum, then IMHO it'd be better to
fail.

[0] https://postgr.es/m/Zu3iMzfiGBTbg3iy%40nathan

-- 
nathan