On 2019-Sep-26, Bruce Momjian wrote:
> On Wed, Sep 11, 2019 at 06:25:38PM -0300, Álvaro Herrera wrote:
> > On 2019-Aug-21, Bruce Momjian wrote:
> >
> > > > 1) How exactly should we report this incompatibility to a user?
> > > > I think it's fine to leave the warnings and also write some hint for the
> > > > user by analogy with other checks.
> > > > "Reset ACL on the problem functions to default in the old cluster to
> > > > continue"
> > >
> > > Yes, I think it is good to at least throw an error during --check so
> > > they don't have to find out during a live upgrade. Odds are it will
> > > require manual repair.
> >
> > I'm not sure what you're proposing here ... are you saying that the user
> > would have to modify the source cluster before pg_upgrade accepts to
> > run? That sounds pretty catastrophic.
>
> Well, right now, pg_upgrade --check succeeds, but the upgrade fails. I
> am proposing, at a minimum, that pg_upgrade --check fails in such cases,
Agreed, that should be a minimum fix.
> with a clear error message about how to fix it.
So the best solution being proposed is to reset the ACL to the default?
So we would be forcing the user to propagate the ACL change manually,
rather than trying to make pg_upgrade propagate it automatically. I
suppose making pg_upgrade would be better, but I'm not sure to what
extent that is a full solution.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
