Re: pg_upgrade fails with non-standard ACL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: pg_upgrade fails with non-standard ACL
Date: 2019-07-28 01:33:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Thu, Jul 18, 2019 at 06:53:12PM +0300, Anastasia Lubennikova wrote:
>> pg_upgrade from 9.6 fails if old cluster had non-standard ACL
>> on pg_catalog functions that have changed between versions,
>> for example pg_stop_backup(boolean).

> Uh, wouldn't this affect any default-installed function where the
> permission are modified? Is fixing only a few functions really helpful?

No, it's just functions whose signatures have changed enough that
a GRANT won't find them. I think the idea is that the set of
potentially-affected functions is determinate. I have to say that
the proposed patch seems like a complete kluge, though. For one
thing we'd have to maintain the list of affected functions in each
future release, and I have no faith in our remembering to do that.

It's also fair to question whether pg_upgrade should even try to
cope with such cases. If the function has changed signature,
it might well be that it's also changed behavior enough so that
any previously-made grants need reconsideration. (Maybe we should
just suppress the old grant rather than transferring it.)

Still, this does seem like a gap in the pg_init_privs mechanism.
I wonder if Stephen has any thoughts about what ought to happen.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-07-28 01:37:54 minor fixes after pgindent prototype fixes
Previous Message Tom Lane 2019-07-28 01:08:50 Re: Testing LISTEN/NOTIFY more effectively