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

From Michael Paquier
Subject Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
Date
Msg-id aZp6mrxzlNc1KmRf@paquier.xyz
Whole thread Raw
In response to Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
List pgsql-bugs
On Sat, Feb 21, 2026 at 12:56:24PM +0100, Alvaro Herrera wrote:
> 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).  Two notes:
>
> 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.

While I get the feeling of urgency, I am wondering if this particular
fix should have been delayed and pushed for next May's release.  We
are already doing one quick release for the regressions found in the
CVE fixes..

Based on my read of the fix, I feel rather safe that this is OK.  But
as I have quoted upthread, the reason why I did not reply yet was to
wait for next week's release to be out before acting.  That's your
code of course, so no objections from here, just a slight doubt about
the timing.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change