From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Bradley Miller <bmiller(at)nuvio(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres List <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: pg_restore problem |
Date: | 2005-02-03 15:25:58 |
Message-ID: | 42024286.9000007@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Fradkin | 2005-02-03 16:14:39 | problem with backup and restore (probaly stupit newb thing) |
Previous Message | Richard Huxton | 2005-02-03 15:15:32 | Re: [PERFORM] Tunning postgresql on linux (fedora core 3) |