public inbox for [email protected]
help / color / mirror / Atom feedRe: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
6+ messages / 3 participants
[nested] [flat]
* Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
@ 2026-02-21 11:56 Álvaro Herrera <[email protected]>
2026-02-21 13:45 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
2026-02-21 15:13 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Laurenz Albe <[email protected]>
2026-02-22 03:40 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Michael Paquier <[email protected]>
0 siblings, 3 replies; 6+ messages in thread
From: Álvaro Herrera @ 2026-02-21 11:56 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected]
On 2026-Feb-05, Laurenz Albe 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). 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.
2. I moved this foreach loop
> @@ -2905,6 +2907,12 @@ AddRelationNotNullConstraints(Relation rel, List *constraints,
> * system-generated name conflicts we just generate another.
> */
> nnnames = NIL;
> + foreach_ptr(CookedConstraint, cons, existing_constraints)
> + {
> + if (cons->name != NULL)
> + nnnames = lappend(nnnames, cons->name);
> + }
> +
> givennames = NIL;
from AddRelationNotNullConstraints to DefineRelation; it seems more
natural for the former to receive a list of constraint names than a list
of CookedConstraints.
Thanks Hüseyin for the report and Laurenz for the fix!
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"How strange it is to find the words "Perl" and "saner" in such close
proximity, with no apparent sense of irony. I doubt that Larry himself
could have managed it." (ncm, http://lwn.net/Articles/174769/)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
2026-02-21 11:56 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
@ 2026-02-21 13:45 ` Álvaro Herrera <[email protected]>
2 siblings, 0 replies; 6+ messages in thread
From: Álvaro Herrera @ 2026-02-21 13:45 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected]
On 2026-Feb-21, Álvaro Herrera wrote:
>
> 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.
As expected, crake reported:
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function (13 filtered out)
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 function with incompatible sub-type changes:
[C] 'function List* AddRelationNotNullConstraints(Relation, List*, List*)' has some sub-type changes:
parameter 4 of type 'List*' was added
I have pushed the update to .abi-compliance-history, and crake is now green.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
2026-02-21 11:56 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
@ 2026-02-21 15:13 ` Laurenz Albe <[email protected]>
2 siblings, 0 replies; 6+ messages in thread
From: Laurenz Albe @ 2026-02-21 15:13 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: [email protected]; [email protected]
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
2026-02-21 11:56 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
@ 2026-02-22 03:40 ` Michael Paquier <[email protected]>
2026-02-23 16:47 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
2 siblings, 1 reply; 6+ messages in thread
From: Michael Paquier @ 2026-02-22 03:40 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; [email protected]
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
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
2026-02-21 11:56 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
2026-02-22 03:40 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Michael Paquier <[email protected]>
@ 2026-02-23 16:47 ` Álvaro Herrera <[email protected]>
2026-02-23 23:20 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Michael Paquier <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Álvaro Herrera @ 2026-02-23 16:47 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; [email protected]
On 2026-Feb-22, Michael Paquier wrote:
> 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..
I debated that with myself before pushing. I thought the risk of
introducing a new bug or problem was pretty low; whereas the bug was
clearly already affecting real-world users in their attempts to migrate
to 18 from earlier versions, so the damage was real.
> 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.
Hmm, what? The only response from you that I see in this thread is
https://postgr.es/m/[email protected]
which was on Feb 10th, which is before the 18.2 release, so you couldn't
have been considering the 18.3 release yet.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists
2026-02-21 11:56 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
2026-02-22 03:40 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Michael Paquier <[email protected]>
2026-02-23 16:47 ` Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
@ 2026-02-23 23:20 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Michael Paquier @ 2026-02-23 23:20 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; [email protected]
On Mon, Feb 23, 2026 at 05:47:46PM +0100, Alvaro Herrera wrote:
> On 2026-Feb-22, Michael Paquier wrote:
>> 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.
>
> Hmm, what? The only response from you that I see in this thread is
> https://postgr.es/m/[email protected]
> which was on Feb 10th, which is before the 18.2 release, so you couldn't
> have been considering the 18.3 release yet.
Well, you are not counting the week of the 18.2 release, this thread
being an item I had on my stack of items to look at once the tags were
applied. It didn't make to the top of the list. It does not matter
much at the end. Thanks for fixing the issue!
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-02-23 23:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-21 11:56 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists Álvaro Herrera <[email protected]>
2026-02-21 13:45 ` Álvaro Herrera <[email protected]>
2026-02-21 15:13 ` Laurenz Albe <[email protected]>
2026-02-22 03:40 ` Michael Paquier <[email protected]>
2026-02-23 16:47 ` Álvaro Herrera <[email protected]>
2026-02-23 23:20 ` Michael Paquier <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox