Feedback-ID: ie3de48e3:Fastmail
Date: Sat, 23 May 2026 05:18:03 -0700
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Pg upgrade bug with NOT NULL NOT VALID
Message-ID: <ahGZu3rmU2zmCWHq@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CALdSSPiTsw=t76-fiksBfjWKji4D2WHN8a17G30L5h1LF34oTA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ahGZu3rmU2zmCWHq%40alvherre.pgsql>
Precedence: bulk

On 2026-May-23, Kirill Reshke wrote:

> On Thu, 21 May 2026 at 22:18, Álvaro Herrera <alvherre@kurilemu.de> wrote:

> > I see two alternatives.  One is to have pg_dump --binary-upgrade choose
> > a constraint name for the not-null with full knowledge of all other
> > constraint names, so that we know to generate a non conflicting one.
> > I suspect this is not easy to code.
> 
> Well, for this option, we need to be told about what other constraint
> names that are about to be created.

Sure.  Of course, pg_dump can run all the queries it needs to obtain
constraint names, so it's certainly doable.

> > The other is much simpler: make pg_upgrade -c warn you about the check
> > constraint name so that you know to rename it before the upgrade.
> 
> I don't think this is good when the database asks you to change your
> DDL because of its internal troubles with something.

OK.  I disagree but I'm not opposed if you want to do it the other way.

If you prefer that I write the patch, that's fine too.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"La espina, desde que nace, ya pincha" (Proverbio africano)