Re: pg_upgrade fails with non-standard ACL

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 +

In response to

Responses

Browse pgsql-hackers by date

  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