Re: vacuumdb: permission denied for schema "pg_temp_7"
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Michael Paquier <michael@paquier.xyz>,
Christophe Pettus <xof@thebuild.com>
Cc: Nathan Bossart <nathandbossart@gmail.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:20:43Z
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 →
-
vacuumdb: Schema-qualify operator in catalog query's WHERE clause.
- eba8cc1af8ec 16.5 landed
- d4ade0bafb75 13.17 landed
- ce6f27857bba 14.14 landed
- 8318f2b170d8 18.0 landed
- 6d047c6a9192 15.9 landed
- 5e0431c32a8f 12.21 landed
- 5bd26e652780 17.1 landed
-
reindexdb: Skip reindexing temporary tables and indexes.
- 9410f7cbf4ff 13.17 landed
- 88e1153cb3c6 14.14 landed
- 92cc21d158f3 15.9 landed
- 653ce5b8b79c 16.5 landed
- 77f154681981 17.1 landed
- 20cfec896c6a 18.0 landed
-
vacuumdb: Skip temporary tables in query to build list of relations
- ef57a713580f 12.21 landed
- 9db4598c9c98 13.17 landed
- 60c618216ddb 14.14 landed
- 74eaa0544abf 15.9 landed
- 1ea4d9c001e6 16.5 landed
- 85cb21df673f 17.1 landed
- 1ab67c9dfaad 18.0 landed
-
Use catalog query to discover tables to process in vacuumdb
- e0c2933a767c 12.0 cited
On 2024/09/24 10:08, Michael Paquier wrote:
> On Mon, Sep 23, 2024 at 11:48:21AM -0700, Christophe Pettus wrote:
>> I'm happy to pick it up iff the current patch submitter doesn't want
>> to continue with it.
>
> Somewhat missed this thread, thanks for the latest activity.
>
> If we apply a restriction on the temporary persistence, then we know
> that vacuumdb will always have a WHERE clause so we can simplify the
> code and remove the business with has_where like in the attached.
LGTM.
> 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.
Sorry if I misunderstood your point.
> The REINDEX one is really something that we need to care about? One
> needs database ownership for a database-level REINDEX, or schema-level
> ownership for the schema-level one. Stricter restrictions apply
> compared to vacuum_rel().
Is ownership really necessary in these cases? A similar issue can easily
happen with reindexdb as follows, so I think that should be fixed as well.
=# CREATE ROLE admin WITH LOGIN;
=# GRANT pg_maintain TO admin;
=# CREATE TEMP TABLE tt (i int primary key);
=# \! bin/reindexdb -U admin -j 2 postgres
reindexdb: error: query failed: ERROR: permission denied for schema pg_temp_0
LINE 4: AND c.oid OPERATOR(pg_catalog.=) 'pg_temp_0.tt'::pg_catalo...
^
reindexdb: detail: Query was: SELECT c.relname, ns.nspname
FROM pg_catalog.pg_class c, pg_catalog.pg_namespace ns
WHERE c.relnamespace OPERATOR(pg_catalog.=) ns.oid
AND c.oid OPERATOR(pg_catalog.=) 'pg_temp_0.tt'::pg_catalog.regclass;
We should probably add a condition like "relpersistence != CppAsString2(RELPERSISTENCE_TEMP)"
to the queries in get_parallel_object_list().
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION