MIME-Version: 1.0
References: <19393-6a82427485a744cf@postgresql.org> <2b3a2cd5f9b6e82fba6ac45b413291b01dd252ea.camel@cybertec.at>
 <61c535617992fff830961ecc09a9c20096bc1f36.camel@cybertec.at>
In-Reply-To: <61c535617992fff830961ecc09a9c20096bc1f36.camel@cybertec.at>
From: Dilip Kumar <dilipbalaut@gmail.com>
Date: Fri, 6 Feb 2026 12:53:33 +0530
Message-ID: <CAFiTN-vPxycE0YeNNTx6_nnD4cGHMP=WA=Yada+Ons=VTGPsdg@mail.gmail.com>
Subject: Re: BUG #19393: pg_upgrade fails with duplicate key violation when
 CHECK constraint named *_not_null exists
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: huseyin.d3r@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFiTN-vPxycE0YeNNTx6_nnD4cGHMP%3DWA%3DYada%2BOns%3DVTGPsdg%40mail.gmail.com>
Precedence: bulk

On Thu, Feb 5, 2026 at 10:22=E2=80=AFPM Laurenz Albe <laurenz.albe@cybertec=
.at> wrote:
>
> On Thu, 2026-02-05 at 15:58 +0100, I wrote:
> > The bug is actually not in pg_upgrade, but in CREATE TABLE.  The attach=
ed patch
> > fixes the problem for me by avoiding given constraint names when genera=
ting
> > the names for NOT NULL constraints.
>
> ... and here is v2, including a regression test.

The fix LGTM. However I have one question, have you considered
validating the name selection logic for other constraint types as
well? I=E2=80=99m specifically thinking about AddRelationNewConstraints().
While I don't have a specific test case yet, is it possible for the
AddRelationNewConstraints to choose a name that is already in use when
adding a new column with a constraint?

--=20
Regards,
Dilip Kumar
Google