From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_upgrade fails with non-standard ACL |
Date: | 2019-09-26 20:04:00 |
Message-ID: | 20190926200400.GA16366@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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,
with a clear error message about how to fix it.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-09-26 20:16:19 | Re: pg_upgrade fails with non-standard ACL |
Previous Message | Alvaro Herrera | 2019-09-26 19:48:28 | Re: Online checksums patch - once again |