Re: pg_restore problem - Mailing list pgsql-sql

From Richard Huxton
Subject Re: pg_restore problem
Date
Msg-id 42024286.9000007@archonet.com
Whole thread Raw
In response to Re: pg_restore problem  (Bradley Miller <bmiller@nuvio.com>)
Responses Re: pg_restore problem  (Bradley Miller <bmiller@nuvio.com>)
List pgsql-sql
Bradley Miller wrote:
> So in the current version I'm running (7.4.6) and I do a pg_dump I have 
> to then manually manipulate the order by doing a -l to get a table of 
> contents and then reorder (just changing the first number; or the oid 
> also??) just to get it to work right?   Does anyone else have these 
> issues?  How exactly can I use this on a mission critical app with flaws 
> like this?   How do other people work with this?  Do they just not dump 
> the files and restore?

The problem(s) are only apparent if you define/redefine objects in a 
certain order. I've tended to encounter them on databases where I've 
extensively reworked elements (particularly functions/views). In 
particular, dumping a restored database always seems OK for me.

With the -l file, you just need to cut & paste the lines into the 
correct order. In practice, I tend to just move half-a-dozen lines to 
the end of the file to get things to work. The crucial bit then is to 
make sure you keep a backup copy of the working order somewhere - you 
have no idea how often I've deleted the file as soon as I've finished 
restoring.

Of course, if you have dynamic functions in say perl/tcl and then base 
views on them there's probably no way for pg_dump to ever figure out the 
correct dependencies.

--  Richard Huxton  Archonet Ltd


pgsql-sql by date:

Previous
From: Richard Huxton
Date:
Subject: Re: [PERFORM] Tunning postgresql on linux (fedora core 3)
Next
From: "Joel Fradkin"
Date:
Subject: problem with backup and restore (probaly stupit newb thing)