|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|