From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Benedikt Grundmann <bgrundmann(at)janestreet(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Problems with pg_upgrade after change of unix user running db. |
Date: | 2015-11-27 16:15:10 |
Message-ID: | 20151127161510.GJ26179@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 27, 2015 at 04:05:46PM +0000, Benedikt Grundmann wrote:
> > [as-proddb(at)nyc-dbc-001 upgrade-logs]$ tail pg_upgrade_dump_16416.log
> > pg_restore: creating CHECK CONSTRAINT seqno_not_null
> > pg_restore: creating CHECK CONSTRAINT seqno_not_null
> > pg_restore: [archiver (db)] Error while PROCESSING TOC:
> > pg_restore: [archiver (db)] Error from TOC entry 8359; 2606 416548282
> CHECK
> > CONSTRAINT seqno_not_null postgres_prod
> > pg_restore: [archiver (db)] could not execute query: ERROR: constraint
> > "seqno_not_null" for relation "js_activity_2011" already exists
> > Command was: ALTER TABLE "js_activity_2011"
> > ADD CONSTRAINT "seqno_not_null" CHECK (("seqno" IS NOT NULL)) NOT
> VALID;
>
> I have no idea, but this is a pg_dump bug or inconsistent system tables,
> rather than a pg_upgrade-specific bug.
>
>
> Any recommendation on how to proceed?
My guess is you are sharing the constraint name "seqno_not_null" with
multiple tables. I think you are going to have to dig into the system
tables to see where that is referenced and fix it.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2015-11-27 16:15:56 | Re: Problems with pg_upgrade after change of unix user running db. |
Previous Message | Benedikt Grundmann | 2015-11-27 16:05:46 | Re: Problems with pg_upgrade after change of unix user running db. |