| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | vaibhave postgres <postgresvaibhave(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, vsekar(at)microsoft(dot)com |
| Subject: | Re: vacuumdb: permission denied for schema "pg_temp_7" |
| Date: | 2024-09-20 20:59:32 |
| Message-ID: | Zu3iMzfiGBTbg3iy@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Sep 20, 2024 at 12:07:31PM -0700, Noah Misch wrote:
> v12 introduced this regression. I suspect it started when commit e0c2933 "Use
> catalog query to discover tables to process in vacuumdb" switched vacuumdb
> from a simple "VACUUM;" command to per-table commands. Non-superuser vacuumdb
> must be rare indeed for this to go unnoticed long enough to leave all
> supported branches affected.
I think the bug actually predates that commit, but it was only broken when
--jobs > 1. Commit e0c2933 just broke the --jobs == 1 case, too.
> That helps, but we'd probably want to do something more general about vacuumdb
> and schema USAGE permission.
Hm. I think filtering out schemas for which you lack USAGE makes sense
when neither --schema nor --table are specified, but if the user lists an
object they can't vacuum, we should probably fail. My current thinking is
that we could still filter when --exclude-schema is used, but I'm curious
what others think.
You might also be interested in this thread about VACUUM and USAGE [0].
> Thanks for the report.
+1
[0] https://postgr.es/m/flat/56596b81-088f-4c0c-9a88-b5f27a7a62e9%40oss.nttdata.com
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2024-09-20 21:50:30 | Re: vacuumdb: permission denied for schema "pg_temp_7" |
| Previous Message | Noah Misch | 2024-09-20 19:07:31 | Re: vacuumdb: permission denied for schema "pg_temp_7" |