Re: [PATCH] improve the pg_upgrade error message

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] improve the pg_upgrade error message
Date: 2021-07-12 12:20:02
Message-ID: 20210712122002.GC2004@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 12, 2021 at 02:06:31PM +0200, Laurenz Albe wrote:
> On Mon, 2021-07-12 at 16:58 +0530, Jeevan Ladhe wrote:
> > While looking into one of the pg_upgrade issue, I found it
> > challenging to find out the database that has the datallowconn set to
> > 'false' that was throwing following error:
> >
> > "All non-template0 databases must allow connections, i.e. their pg_database.datallowconn must be true"
> >
> > It can be argued that we can query the pg_database
> > catalog and find that out easily, but at times it is challenging to get
> > that from the customer environment.
> >
> > With attached patch, now I get following error:
> > "All non-template0 databases must allow connections, i.e. their pg_database.datallowconn must be true; database "mydb" has datallowconn set to false."
>
> I am in favor of that in principle, but I think that additional information
> should be separate line.

I think the style for this kind of error is established by commit 1634d3615.
This shows "In database: ..."

More importantly, if you're going to show the name of the problematic DB, you
should show the name of *all* the problem DBs. Otherwise it gives the
impression the upgrade will progress if you fix just that one.

The admin might fix DB123, restart their upgrade procedure, spend 5 or 15
minutes with that, only to have it then fail on DB1234.

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tushar 2021-07-12 12:21:06 Re: refactoring basebackup.c
Previous Message Thomas Munro 2021-07-12 12:18:15 Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)