Re: Problems with pg_upgrade after change of unix user running db.

On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian <bruce(at)momjian(dot)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(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?