Re: Problems with pg_upgrade after change of unix user running db.
От | Bruce Momjian |
---|---|
Тема | Re: Problems with pg_upgrade after change of unix user running db. |
Дата | |
Msg-id | 20151127161510.GJ26179@momjian.us обсуждение исходный текст |
Ответ на | Re: Problems with pg_upgrade after change of unix user running db. (Benedikt Grundmann <bgrundmann@janestreet.com>) |
Ответы |
Re: Problems with pg_upgrade after change of unix user
running db.
|
Список | 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 по дате отправления: