Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: huseyin.d3r@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2026-02-21T15:13:59Z
Lists: pgsql-bugs, pgsql-hackers
On Sat, 2026-02-21 at 12:56 +0100, Álvaro Herrera 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. > > Thanks for this! I have pushed it now to 18 and master (right before > the embargo for next week's release -- not really apologizing about > that, since this is clearly something that's going to bite users as they > move up to 18). Thank you, and thanks for the code improvements. > 1. this will cause an ABI break report for AddRelationNotNullConstraints > in branch 18. I considered the idea of adding a shim function > preserving the original API, but I think this is not a function likely > to be used by third-party code. So I'll address this by adding an entry > to .abi-compliance-history instead. I decided not to worry about changing the signature of that global function, because it is only used in a single place and - like you - I deem it unlikely to be useful elsewhere. Yours, Laurenz Albe
Commits
-
Update .abi-compliance-history for AddRelationNotNullConstraints().
- 70eca789eaaa 18.3 landed
-
Avoid name collision with NOT NULL constraints
- 8d9a97e0bb6d 18.3 landed
- 0eeffd31bf9b 19 (unreleased) landed