Re: pg_upgrade fails with non-standard ACL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade fails with non-standard ACL
Date
Msg-id 26687.1564277625@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade fails with non-standard ACL  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade fails with non-standard ACL  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Testing LISTEN/NOTIFY more effectively
Next
From: Andres Freund
Date:
Subject: minor fixes after pgindent prototype fixes