Horton

Re: vacuumdb: permission denied for schema "pg_temp_7"

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Nathan Bossart <nathandbossart@gmail.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:49:12Z
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 2024/09/24 23:26, Nathan Bossart wrote:
> 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.

This could be debatable. To be honest, if I run something like vacuumdb mydb,
*I* expect all eligible tables in that database to be vacuumed. If I forget to
grant the necessary privileges to the role, I’d prefer to see errors from
vacuumdb so I can fix the permissions.

If we decide to skip tables without enough privilege, I’d prefer adding
an option like --skip-unprivileged-tables rather than changing the default behavior.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION