From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Chris Travers <chris(at)travelamericas(dot)com>, "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Upgrading from 7.1 |
Date: | 2005-07-28 05:54:47 |
Message-ID: | 20691.1122530087@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On Wed, Jul 27, 2005 at 05:13:01PM -0700, Chris Travers wrote:
>> Thomas F. O'Connell wrote:
>>> I'm not sure why you're getting errors. Is there a reason you did the
>>> schema dump separately from the data dump rather than a monolithic
>>> dump/restore?
>
>> I seem to remember encountering an issue some time ago with pg_dump
>> dumping tables in an order that prevented them from being reloaded.
> This problem is solved in 8.0's pg_dump. Not sure if 7.1 has enough
> information in catalogs to make the algorithm run correctly -- I wonder
> if pg_depend is needed, because AFAIR there was no pg_depend in 7.1.
There was not, and current pg_dump can't promise a safe dump order when
dumping from a server too old to have correct dependency info.
My advice is to use a recent pg_dump with -Fc option, so that you can
twiddle the load order using pg_restore's options to control the order.
7.1 to 8.0 is definitely a big jump --- it'd be worth your time to work
on schema-level incompatibilities (that is, try to load and work with
a "pg_dump -s" dump) before you even think of moving any data.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-28 06:40:15 | Re: [GENERAL] MySQL to PostgreSQL, was ENUM type |
Previous Message | Gregory Youngblood | 2005-07-28 04:57:57 | Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type |