Re: Problems with pg_upgrade after change of unix user running db. - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Problems with pg_upgrade after change of unix user running db.
Date
Msg-id 20151127161510.GJ26179@momjian.us
Whole thread Raw
In response to Re: Problems with pg_upgrade after change of unix user running db.  (Benedikt Grundmann <bgrundmann@janestreet.com>)
Responses Re: Problems with pg_upgrade after change of unix user running db.
List pgsql-general
On Fri, Nov 27, 2015 at 04:05:46PM +0000, Benedikt Grundmann wrote:
>     > [as-proddb@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@momjian.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                             +


pgsql-general by date:

Previous
From: Benedikt Grundmann
Date:
Subject: Re: Problems with pg_upgrade after change of unix user running db.
Next
From: Adrian Klaver
Date:
Subject: Re: Problems with pg_upgrade after change of unix user running db.