Message-ID: <42024286.9000007@archonet.com>
Date: Thu, 03 Feb 2005 15:25:58 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: Bradley Miller <bmiller@nuvio.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	Postgres List <pgsql-sql@postgresql.org>
Subject: Re: pg_restore problem
References: <74EFBC01-7557-11D9-AC7D-000D932ED682@nuvio.com>
	<6725.1107379479@sss.pgh.pa.us>
	<21AFCC70-75EE-11D9-AC7D-000D932ED682@nuvio.com>
In-Reply-To: <21AFCC70-75EE-11D9-AC7D-000D932ED682@nuvio.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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