| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | huseyin(dot)d3r(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists |
| Date: | 2026-02-06 07:23:33 |
| Message-ID: | CAFiTN-vPxycE0YeNNTx6_nnD4cGHMP=WA=Yada+Ons=VTGPsdg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Thu, Feb 5, 2026 at 10:22 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2026-02-06 09:10:31 | Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists |
| Previous Message | PG Bug reporting form | 2026-02-06 03:08:25 | BUG #19395: Postgres master: undeclared function 'typeof_unqual' |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2026-02-06 07:28:06 | Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 |
| Previous Message | Jakub Wartak | 2026-02-06 07:19:02 | Re: [PING] fallocate() causes btrfs to never compress postgresql files |