On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian <br...@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?