Re: vacuumdb: permission denied for schema "pg_temp_7"
От | Nathan Bossart |
---|---|
Тема | Re: vacuumdb: permission denied for schema "pg_temp_7" |
Дата | |
Msg-id | ZvLMDXv1XrxuJfT3@nathan обсуждение исходный текст |
Ответ на | Re: vacuumdb: permission denied for schema "pg_temp_7" (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: vacuumdb: permission denied for schema "pg_temp_7"
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: