Re: Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

SCHLEMMER Norbert <[email protected]> Wed, 29 Oct 2025 08:59:46 +0000
Newsgroups gmane.comp.bug-tracking.roundup.user
Message-ID <DU2PR01MB85572085A7C3A7B26DA6BB10E8FAA@DU2PR01MB8557.eurprd01.prod.exchangelabs.com>
Hi Ralf

What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to=
 "2.5.0 / PostgreSQL 18" and for migrating to a different host with Debian =
13 / Trixie?

Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.=
0-1?
I did this and didn't find any problems during testing. Is this procedure p=
ermissible and recommended?
If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/=
restore.

Thanks
Norbert


-----Urspr=FCngliche Nachricht-----
Von: Ralf Schlatterbeck <[email protected]> =

Gesendet: Mittwoch, 29. Oktober 2025 09:29
An: [email protected]
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: dupl=
icate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> Hello All
>
> Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and =

> Debian 13 / Trixie as host
>
> An export was created from the productive Roundup instance 2.3.0.
> After importing in version 2.5.0, new messages can be added to an =

> existing issue but creating a new issue result in this violation; see =

> logs attached (the import process takes approximately 6 hours...).

Umm, how much data do you have in that database?
If you're migrating between the same version of roundup *and* the same data=
base, an SQL dump/restore should be *much* faster.

Note that using the roundup-export / roundup-import is not recommended for =
version upgrade, that should happen in-place. This might be the reason of t=
he error-message you're seeing.

> UniqueViolation: duplicate key value violates unique constraint "_issue_p=
key" DETAIL: Key (id)=3D(3) already exists.    Python 3.13.5
> /usr/local/bin/python3.13

Hmm, this might be because a retired node (e.g. an issue) is first created =
and then retired, it could produce a duplicate primary key if a non-retired=
 node *with the same key* already exists.

But under normal circumstances duplicate primary keys should not occur (eve=
n including retired nodes).

Kind regards
Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]


_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users