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

From Adrian Klaver
Subject Re: Problems with pg_upgrade after change of unix user running db.
Date
Msg-id 565881BC.7060607@aklaver.com
Whole thread Raw
In response to Re: Problems with pg_upgrade after change of unix user running db.  (Benedikt Grundmann <bgrundmann@janestreet.com>)
List pgsql-general
On 11/27/2015 08:05 AM, Benedikt Grundmann wrote:
>
>
> On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian <bruce@momjian.us
> <mailto:bruce@momjian.us>> wrote:
>
>     On Fri, Nov 27, 2015 at 09:38:54AM +0000, Benedikt Grundmann wrote:
>     > That worked (I also swapped the password columns so that I don't have to change
>     > pgpass entries).  But I then ran into a different problem a little later on.  I
>     > thought I quickly mention it here in case somebody can point me into the right
>     > direction:
>     >
>     ...
>     > Restoring database schemas in the new cluster
>     >
>     > *failure*
>     > Consult the last few lines of "pg_upgrade_dump_16416.log" for
>     > the probable cause of the failure.
>     > child worker exited abnormally: Invalid argument
>     >
>     > *failure*
>     > Consult the last few lines of "pg_upgrade_server.log" for
>     > the probable cause of the failure.
>     >
>     > [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?
>

Not sure that it matters, from one of your previous posts:

"
*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure."

What do the last lines in pg_upgrade_server.log show?

--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Problems with pg_upgrade after change of unix user running db.
Next
From: Tom Lane
Date:
Subject: Re: Old source code needed