Обсуждение: 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/

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)

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)