Thread: problem with pg_dump and pg_restore
Hi I try to move my datas from a postresql 7.3.2 to a postgresql 7.4.1. The database was dumped with: pg_dumpall -g GLOBALobjects.sql pg_dump -s DATABASE > DBschema.sql pg_dump -Fc DATABASE > DBdata.tar and rebuilt on the new system with: createdb DATABASE psql DATABASE < GLOBALobjects.sql psql DATABASE < tsearch2.sql psql DATABASE < DBschema.sql pg_restore -N -a -v -d DATABASE DBdata.tar All semms to go well except the restoring. pg_restore prints the following report: fi@susi179:/tmp> pg_restore -N -a -v -d codasdb codasdbdump-d.tar pg_restore: connecting to database for restore pg_restore: executing SEQUENCE SET anschrift_ansid_seq : pg_restore: executing SEQUENCE SET dokument_docnum_paper_seq pg_restore: restoring data for table "linkthemen" pg_restore: restoring data for table "links" pg_restore: restoring data for table "anschrift" pg_restore: restoring data for table "kontakt" pg_restore: restoring data for table "mitarbeiter" pg_restore: restoring data for table "kunde" pg_restore: restoring data for table "kontaktperson" pg_restore: restoring data for table "versuch" pg_restore: [archiver (db)] could not execute query: ERROR: insert or update on table "versuch" violates foreign key constraint "$1" DETAIL: Key (proid)=(0) is not present in table "projekt". pg_restore: *** aborted because of error Why are the tables not restored or better dumped in the correct order? Is there a solution to solve this problem? Thanks for any help Ulrich -- Ulrich G. Fischer Dipl. Natw. ETH Center Aerodynamics Ruag Aerospace P.O. Box 301 CH-6032 Emmen Tel. +41 41 268 23 53 Fax. +41 41 268 38 97 ulrich.fischer@aerodynamics.ch www.ruag.com
...and on Wed, Apr 21, 2004 at 02:46:54PM +0200, Fischer Ulrich used the keyboard: > Hi > > I try to move my datas from a postresql 7.3.2 to a postgresql 7.4.1. The > database was dumped with: > > pg_dumpall -g GLOBALobjects.sql > pg_dump -s DATABASE > DBschema.sql > pg_dump -Fc DATABASE > DBdata.tar > Why the schema/data separation? One important freedom you get when combining schema and data in the dumps is you can alter it after you imported the data and thus avoid cyclic dependencies where existance of one foreign key mandates the existance of another, which refers to the first one. For now though, try eliminating all constraints from the schema dump and ALTERing the tables after you imported the data. Hope this helped, -- Grega Bremec Senior Administrator Noviforum Ltd., Software & Media http://www.noviforum.si/
Attachment
The schema/data separation is higly recommended in the HowTo of tsearch2. Thanks for your idea, I'l try it! Ulrich Grega Bremec wrote: > ...and on Wed, Apr 21, 2004 at 02:46:54PM +0200, Fischer Ulrich used the keyboard: > >>Hi >> >>I try to move my datas from a postresql 7.3.2 to a postgresql 7.4.1. The >>database was dumped with: >> >> pg_dumpall -g GLOBALobjects.sql >> pg_dump -s DATABASE > DBschema.sql >> pg_dump -Fc DATABASE > DBdata.tar >> > > > Why the schema/data separation? One important freedom you get when combining > schema and data in the dumps is you can alter it after you imported the data > and thus avoid cyclic dependencies where existance of one foreign key mandates > the existance of another, which refers to the first one. > > For now though, try eliminating all constraints from the schema dump and > ALTERing the tables after you imported the data. > > Hope this helped, -- Ulrich G. Fischer Dipl. Natw. ETH Center Aerodynamics Ruag Aerospace P.O. Box 301 CH-6032 Emmen Tel. +41 41 268 23 53 Fax. +41 41 268 38 97 ulrich.fischer@aerodynamics.ch www.ruag.com
When I tried to use the 7.3.2 dump, and use 7.4.1 import, I had several issues- mostly with data. I actually had to dump with the 7.4.1 dumpall command, upgrade the DB to 7.4.1, and then everything imported correctly. Hope this helps, Corey Grega Bremec <grega.bremec@novifor To: Fischer Ulrich <ulrich.fischer@aerodynamics.ch> um.si> cc: pgsql-admin@postgresql.org Sent by: Subject: Re: [ADMIN] problem with pg_dump and pg_restore pgsql-admin-owner@pos tgresql.org 04/21/2004 08:28 AM ...and on Wed, Apr 21, 2004 at 02:46:54PM +0200, Fischer Ulrich used the keyboard: > Hi > > I try to move my datas from a postresql 7.3.2 to a postgresql 7.4.1. The > database was dumped with: > > pg_dumpall -g GLOBALobjects.sql > pg_dump -s DATABASE > DBschema.sql > pg_dump -Fc DATABASE > DBdata.tar > Why the schema/data separation? One important freedom you get when combining schema and data in the dumps is you can alter it after you imported the data and thus avoid cyclic dependencies where existance of one foreign key mandates the existance of another, which refers to the first one. For now though, try eliminating all constraints from the schema dump and ALTERing the tables after you imported the data. Hope this helped, -- Grega Bremec Senior Administrator Noviforum Ltd., Software & Media http://www.noviforum.si/ (See attached file: att4aa3m.dat)
Attachment
Corey, In my case, I have tried using the 7.4.1 pg_dump in 7.2.3, and it was missing a lot of libraries...did that happen in your case? I am wondering if it's really possible in the first place. Thanks, Anjan -----Original Message----- From: Corey.Brune@transplace.com [mailto:Corey.Brune@transplace.com] Sent: Wednesday, April 21, 2004 12:06 PM To: Grega Bremec Cc: pgsql-admin@postgresql.org; pgsql-admin-owner@postgresql.org; Fischer Ulrich Subject: Re: [ADMIN] problem with pg_dump and pg_restore When I tried to use the 7.3.2 dump, and use 7.4.1 import, I had several issues- mostly with data. I actually had to dump with the 7.4.1 dumpall command, upgrade the DB to 7.4.1, and then everything imported correctly. Hope this helps, Corey Grega Bremec <grega.bremec@novifor To: Fischer Ulrich <ulrich.fischer@aerodynamics.ch> um.si> cc: pgsql-admin@postgresql.org Sent by: Subject: Re: [ADMIN] problem with pg_dump and pg_restore pgsql-admin-owner@pos tgresql.org 04/21/2004 08:28 AM ...and on Wed, Apr 21, 2004 at 02:46:54PM +0200, Fischer Ulrich used the keyboard: > Hi > > I try to move my datas from a postresql 7.3.2 to a postgresql 7.4.1. The > database was dumped with: > > pg_dumpall -g GLOBALobjects.sql > pg_dump -s DATABASE > DBschema.sql > pg_dump -Fc DATABASE > DBdata.tar > Why the schema/data separation? One important freedom you get when combining schema and data in the dumps is you can alter it after you imported the data and thus avoid cyclic dependencies where existance of one foreign key mandates the existance of another, which refers to the first one. For now though, try eliminating all constraints from the schema dump and ALTERing the tables after you imported the data. Hope this helped, -- Grega Bremec Senior Administrator Noviforum Ltd., Software & Media http://www.noviforum.si/ (See attached file: att4aa3m.dat)