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