Re: Upgrade issue (again).

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Upgrade issue (again).
Date: 2001-05-17 05:36:57
Message-ID: 3.0.5.32.20010517133657.00f0e100@192.228.128.13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 04:50 PM 16-05-2001 -0400, Lamar Owen wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I am loathe to even bring this up, but with two messages today about it, I
am
>going to be short and sweet:
>
>We don't have a reasonable upgrade path. ASCII dump->install
>new->initdb->restore is not a reasonable upgrade. It is confusing to the
>newbie, and should be fixed. We used to have an upgrade path in pg_upgrade

>time, Bruce!). Furthermore, the dump/restore cycle is a pain in the neck
when
>tables get larger than a few hundred megabytes. It's worse when the newer

I won't mind a better upgrade method. But so far I pipe the dump into gzip,
and the resulting file is of manageable size.

What I find annoying is that pg_dumpall doesn't support username and
password. So far I just do a pg_dump of the relevant databases, and
recreate the users manually when installing.

Also to reload the file I do:
zcat gzippedusernameandpassword.gz dbfile.gz | psql

That's a bit ugly :).

Cheerio,
Link.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Myers 2001-05-17 07:24:28 "End-to-end" paper
Previous Message Forest Wilkinson 2001-05-17 02:18:51 Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1