| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | vaibhave postgres <postgresvaibhave(at)gmail(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Bug List <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-24 01:13:23 |
| Message-ID: | FA25664E-EDD5-42BE-AA25-1321E0A0C8BC@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On Sep 23, 2024, at 18:09, vaibhave postgres <postgresvaibhave(at)gmail(dot)com> wrote:
> Yes I plan on continuing with working this.
Great!
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.
If it seems reasonable, I'm happy to do it in a separate patch.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vaibhave postgres | 2024-09-24 01:35:41 | Re: vacuumdb: permission denied for schema "pg_temp_7" |
| Previous Message | vaibhave postgres | 2024-09-24 01:09:53 | Re: vacuumdb: permission denied for schema "pg_temp_7" |