Re: Upgrading from 7.1

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

In response to

Browse pgsql-general by date

  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