Fri, 10 Apr 2026 04:38:48 +0000 https://bugs.horde.org/ticket/9835 db schema update for h3->h4 conversion when i did db schema conversion as part of h3->h4 upgrade i got the following: SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "imp_sentmail" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "ingo_rules" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "turba_shares" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "kronolith_shares" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "nag_shares" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "mnemo_shares" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "horde_groups" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "horde_histories" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "horde_perms" are not allowed SQLSTATE[42P16]: Invalid table definition: 7 ERROR: multiple primary keys for table "horde_vfs" are not allowed database backend is postgres Thu, 07 Apr 2011 15:49:07 +0000 https://bugs.horde.org/ticket/9835#t63251 Which version of Postgres? Fri, 08 Apr 2011 12:46:08 +0000 https://bugs.horde.org/ticket/9835#t63312 > Which version of Postgres? postgresql84-libs-8.4.5-1.el5_5.1 postgresql84-server-8.4.5-1.el5_5.1 postgresql84-8.4.5-1.el5_5.1 postgresql84-devel-8.4.5-1.el5_5.1 Fri, 08 Apr 2011 14:53:00 +0000 https://bugs.horde.org/ticket/9835#t63322 Are you able to run PHPUnit tests on that server? Tue, 19 Apr 2011 16:17:59 +0000 https://bugs.horde.org/ticket/9835#t63922 > Are you able to run PHPUnit tests on that server? nope Thu, 28 Apr 2011 16:45:57 +0000 https://bugs.horde.org/ticket/9835#t64271 Not much we can do then. It works fine on our Postgres test system with 8.4.8. Wed, 18 May 2011 15:51:38 +0000 https://bugs.horde.org/ticket/9835#t64796 I see this problem. The reason it happens on my system, is that the primary key constraints have different names than those that the upgrade script is expecting. It attempts to drop the primary key using an incorrect name which fails, then adds it back again. The add of course fails with the reported message. The postgres version is 8.4.2 on centos5, although the database was originally created on a much earlier version. Running the following commands before the upgrade, allows the upgrade to run on my installation. alter table imp_sentmail drop constraint imp_primary_idx; alter table turba_shares drop constraint turba_shares_pkey_idx; alter table kronolith_shares drop constraint kronolith_shares_pkey_idx; alter table ingo_shares drop constraint ingo_shares_primary_idx; alter table ingo_rules drop constraint ingo_rules_primary_idx; alter table mnemo_shares drop constraint mnemo_shares_pkey_idx; alter table nag_shares drop constraint nag_shares_pkey_idx; alter table horde_groups drop constraint group_primary_idx; alter table horde_histories drop constraint history_primary_idx; alter table horde_perms drop constraint perms_primary_idx; alter table horde_vfs drop constraint vfs_primary_idx; There is then a problem with rampage_types which is resolved by running the failed upgrade again. Thu, 19 May 2011 21:13:09 +0000 https://bugs.horde.org/ticket/9835#t64879 I did exactly what you described in your post - manually dropped indexes, then upgrade script was able to create new ones. Thanks that you confirm my theory. > I see this problem. > > The reason it happens on my system, is that the primary key constraints have > different names than those that the upgrade script is expecting. It > attempts to > drop the primary key using an incorrect name which fails, then adds it back > again. The add of course fails with the reported message. > > The postgres version is 8.4.2 on centos5, although the database was > originally > created on a much earlier version. > > Running the following commands before the upgrade, allows the upgrade to > run on my installation. > > alter table imp_sentmail drop constraint imp_primary_idx; > alter table turba_shares drop constraint turba_shares_pkey_idx; > alter table kronolith_shares drop constraint kronolith_shares_pkey_idx; > alter table ingo_shares drop constraint ingo_shares_primary_idx; > alter table ingo_rules drop constraint ingo_rules_primary_idx; > alter table mnemo_shares drop constraint mnemo_shares_pkey_idx; > alter table nag_shares drop constraint nag_shares_pkey_idx; > alter table horde_groups drop constraint group_primary_idx; > alter table horde_histories drop constraint history_primary_idx; > alter table horde_perms drop constraint perms_primary_idx; > alter table horde_vfs drop constraint vfs_primary_idx; > > There is then a problem with rampage_types which is resolved by running the > failed upgrade again. > Thu, 19 May 2011 21:24:24 +0000 https://bugs.horde.org/ticket/9835#t64881 > The reason it happens on my system, is that the primary key constraints have > different names than those that the upgrade script is expecting. It > attempts to > drop the primary key using an incorrect name which fails, then adds it back > again. The add of course fails with the reported message. So, the question is why? The default names for primary key constraints in PostgreSQL are table_pkey. Why are yours table_idx? Thu, 30 Jun 2011 10:09:12 +0000 https://bugs.horde.org/ticket/9835#t66028 > So, the question is why? The default names for primary key > constraints in PostgreSQL are table_pkey. Why are yours table_idx? I have database dumps every day for the time I have used horde. So I can tell exactly when the unexpected primary key names appeared. Unfortunately, it looks like I both upgraded the database and horde (to 1.2.5 from an unknown version) on that date, so I can't tell if it was an artefact of the database upgrade or the horde upgrade. I guess its possible that one of the upgrades partially failed and I had to fix the primary keys by hand but I don't particularly remember doing that. The names do seem to be a bit inconsistent to be the result of an automatic process. I can investigate further if you have anything you want me to check. Fri, 01 Jul 2011 20:53:35 +0000 https://bugs.horde.org/ticket/9835#t66105 Well, the point is that primary keys don't have a name. At least not in standard SQL and that's what we use in Horde (3). Postgres uses names internally though, and makes them up from the table name. Fri, 01 Jul 2011 21:01:51 +0000 https://bugs.horde.org/ticket/9835#t66108 In the database dump the table is created first without any primary key and then the primary key is added with a given name eg: ALTER TABLE ONLY imp_sentmail ADD CONSTRAINT imp_primary_idx PRIMARY KEY (sentmail_id); So it can be named anything, but yes, I can't imagine how it got to be the wrong name in the first place. The other person that had the problem with exactly the same tables as me, so they may be able to shed some light on it - it can't be just peculiar to me. Fri, 01 Jul 2011 21:39:31 +0000 https://bugs.horde.org/ticket/9835#t66109 Dan? Sat, 30 Jul 2011 12:08:07 +0000 https://bugs.horde.org/ticket/9835#t66663 Should be fixed in recent Horde_Db versions. Tue, 06 Sep 2011 16:55:03 +0000 https://bugs.horde.org/ticket/9835#t67333