From: | Bradley Miller <bmiller(at)nuvio(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres List <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: pg_restore problem |
Date: | 2005-02-03 14:16:01 |
Message-ID: | 21AFCC70-75EE-11D9-AC7D-000D932ED682@nuvio.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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?
On Feb 2, 2005, at 3:24 PM, Tom Lane wrote:
> Bradley Miller <bmiller(at)nuvio(dot)com> writes:
>> I'm attempting to restore a dump from one server to another (one is a
>> Mac and one is a Linux base, if that makes any difference). I keep
>> running into issues like this:
>
>> pg_restore: [archiver (db)] could not execute query: ERROR: function
>> public.random_page_link_id_gen() does not exist
>
> Is this a problem of items in the dump being in the wrong order (ie,
> there's a forward reference to random_page_link_id_gen())?
>
>> Any suggestions on how to get around this problem?
>
> Use 8.0 ... or use pg_restore's -L/-l options to manually adjust the
> load order. Pre-8.0 versions of pg_dump are easily fooled if you use
> ALTER to make earlier-created objects reference later-created objects.
>
> regards, tom lane
>
>
Bradley Miller
NUVIO CORPORATION
Phone: 816-444-4422 ext. 6757
Fax: 913-498-1810
http://www.nuvio.com
bmiller(at)nuvio(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2005-02-03 14:52:04 | Re: Tunning postgresql on linux (fedora core 3) |
Previous Message | Michael Glaesemann | 2005-02-03 14:14:45 | Re: pg primary key bug? |