Horton

Re: vacuumdb: permission denied for schema "pg_temp_7"

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Christophe Pettus <xof@thebuild.com>
Cc: vaibhave postgres <postgresvaibhave@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@oss.nttdata.com>, Noah Misch <noah@leadboat.com>, PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>, vsekar@microsoft.com
Date: 2024-09-24T14:30: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 Mon, Sep 23, 2024 at 06:13:23PM -0700, Christophe Pettus wrote:
> One related but not identical thing that has come up with vacuumdb is
> that it terminates if it's not able to connect to any database that it
> finds in the initial query.  This can happen if pg_hba.conf denies the
> user that is running vacuumdb access to a database that comes up during
> --all.  Some hosting providers (in particular, Google) create restricted
> databases in the cluster that a customer role can't get access to.  This
> pretty much defeats --analyze-in-stages.  My suggested fix was to
> terminate with an error if the initial connection fails, but continue
> with a warning if further connections fail.

I think it'd be fine to continue with a warning when --all is used, but if
you specify a --dbname that you cannot connect to, then I think it should
fail.

-- 
nathan