Re: [HACKERS] PG_UPGRADE status?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] PG_UPGRADE status?
Date: 1999-09-08 21:33:32
Message-ID: 1222.936826412@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> [ messiness required to upgrade versions by piping data from a
> pg_dumpall to a psql talking to the new version ]

It'd be considerably less messy, and safer, if you were willing to
stick the pg_dump output into a file rather than piping it on the fly.
Then (a) you wouldn't need to run both versions concurrently, and
(b) you'd have a dump backup if something went wrong during the install.

If you compressed the dump file, which is easy enough, it'd probably
also take less disk space than doing it the other way. A compressed
dump should usually be a good deal smaller than the database equivalent;
if you do an on-the-fly transfer then the peak usage is two full
on-disk copies of the database...

> You can see how pg_upgrade would be useful in such a scenario, no?

pg_upgrade is hardly a magic panacea --- if the on-disk formats are
at all different, then you really have little choice short of a dump
under the old version and reload under the new. At most pg_upgrade
might help automate that process a little more.

We may have lost the option of pg_upgrade-like upgrades anyway.
I'm still waiting to hear Vadim's opinion about whether pg_upgrade
can be made safe under MVCC.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Simms 1999-09-08 21:41:04 Re: [HACKERS] Postgres Performance
Previous Message Edwin Ramirez 1999-09-08 21:05:38 Re: [HACKERS] Postgres Performance