Request a Demo
Home   >   mailing lists

Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists - Mailing list pgsql-bugs

From Dilip Kumar
Subject Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
Date
Msg-id CAFiTN-vPxycE0YeNNTx6_nnD4cGHMP=WA=Yada+Ons=VTGPsdg@mail.gmail.com
Whole thread
In response to Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
List pgsql-bugs
Tree view 
On Thu, Feb 5, 2026 at 10:22 PM 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 attached patch
> > fixes the problem for me by avoiding given constraint names when generating
> > 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’m 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?

--
Regards,
Dilip Kumar
Google

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #19395: Postgres master: undeclared function 'typeof_unqual'
Next
From: Laurenz Albe
Date:
Subject: Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists