Re: Pg upgrade bug with NOT NULL NOT VALID

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pg upgrade bug with NOT NULL NOT VALID
Date: 2026-05-23 12:18:03
Message-ID: ahGZu3rmU2zmCWHq@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-May-23, Kirill Reshke wrote:

> On Thu, 21 May 2026 at 22:18, Álvaro Herrera <alvherre(at)kurilemu(dot)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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniil Davydov 2026-05-23 13:29:09 ERROR during COMMIT PREPARED can leave orphaned locks
Previous Message Yushu Chen 2026-05-23 12:10:26 [PATCH] Add regression test for mismatched ENCODING and LOCALE in CREATE DATABASE