Re: Pg upgrade bug with NOT NULL NOT VALID

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
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 10:14:42
Message-ID: CALdSSPiTsw=t76-fiksBfjWKji4D2WHN8a17G30L5h1LF34oTA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 21 May 2026 at 22:18, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> Hi,
>

Hi, thank you for looking into this.

> 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. So, pg_dump will need to issue an
SQL that says: please create this relation, but also never choose
name1 to anything in the process. I guess this is not committable...
Maybe you can clarify the design here?

> 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.

I also think we should make pg_upgrade just work in this case.

--
Best regards,
Kirill Reshke

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message wenhui qiu 2026-05-23 10:17:26 Re: Report oldest xmin source when autovacuum cannot remove tuples
Previous Message Imran Zaheer 2026-05-23 09:19:30 Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)