Re: [HACKERS] PG_UPGRADE status? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] PG_UPGRADE status?
Date
Msg-id 1222.936826412@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen <lamar.owen@wgcr.org>)
List pgsql-hackers
Lamar Owen <lamar.owen@wgcr.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


pgsql-hackers by date:

Previous
From: Edwin Ramirez
Date:
Subject: Re: [HACKERS] Postgres Performance
Next
From: Michael Simms
Date:
Subject: Re: [HACKERS] Postgres Performance