| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: 12 to 13 migration, the privs error with pg_pltemplate |
| Date: | 2020-12-17 18:40:17 |
| Message-ID: | 20201217184017.GA23245@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Wed, Dec 9, 2020 at 12:19:18PM -0500, Tom Lane wrote:
> Scott Ribe <scott_ribe(at)elevated-dev(dot)com> writes:
> > Any other suggestions? What could possibly be triggering this GRANT?
>
> Ah, I'm sorry, I pointed you at the wrong catalog entirely. It's
> not pg_default_acl that controls this, it's pg_init_privs. I believe
> what pg_dump is doing is emitting GRANT commands that replicate
> the difference between pg_pltemplate's current actual privileges and
> what is shown for it in pg_init_privs. So you need to make those
> two things match, in whichever way is easiest.
Should pg_dump or pg_upgrade be detecting and reporting these things,
rather than requiring this analysis by the user?
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-12-17 18:50:11 | Re: 12 to 13 migration, the privs error with pg_pltemplate |
| Previous Message | Tom Lane | 2020-12-17 14:05:41 | Re: Error in getNextException No space left on device Call getNextException to see other errors in the batch. (java.sql.BatchUpdateException) |