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 |
Message-ID: | 26687.1564277625@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
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 |