From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-09 17:33:31 |
Message-ID: | 68634B7E-3AD0-42A3-9A2D-EC3988E755E4@elevated-dev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> On Dec 9, 2020, at 10:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
OK, now *THAT* turned up a lot of suspicious entries. It will be a bit before I can try straightening that out. But there's a lot of tables in pg_catalog that have privs listed for the user in question.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-12-09 18:49:25 | Re: 12 to 13 migration, the privs error with pg_pltemplate |
Previous Message | Tom Lane | 2020-12-09 17:19:18 | Re: 12 to 13 migration, the privs error with pg_pltemplate |