On Fri, Sep 13, 2013 at 11:17 AM, Patrick Dung <patrick_dkt@yahoo.com.hk> wrote:
>
> ________________________________
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Stephen Frost <sfrost@snowman.net>
> Cc: Ivan Voras <ivoras@freebsd.org>; pgsql-general@postgresql.org
> Sent: Friday, September 13, 2013 9:58 PM
>
> Subject: Re: [GENERAL] Major upgrade of PostgreSQL and MySQL
>
>>> * Ivan Voras (ivoras@freebsd.org) wrote:
>>>> If I read the documentation correctly
>>>> (http://www.postgresql.org/docs/9.3/static/pgupgrade.html), it needs
>>>> oldbindir and newbindir arguments pointing to the directories of
>>>> PostgreSQL executables for the old and new versions, making it basically
>>>> unusable for upgrading systems which are maintained with packages
>>>> instead of individually compiling & installing custom versions of
>>>> PostgreSQL, right? (except possibly Debian which may allow multiple pg
>>>> versions to be installed, I haven't tried it).
>>
>>> Uhm, don't basically all Debian-based and RedHat-based distributions
>>> support having multiple major versions installed concurrently? It's a
>>> pretty reasonable thing to need and, imv anyway, all packaging of PG
>>> should support it.
>>
>>In Red Hat's own packaging, you should temporarily install the
>>postgresql-upgrade RPM, which contains pg_upgrade as well as a copy
>>of the previous-generation postmaster. If you use Devrim's packages,
>>I think he more nearly follows the Debian approach. Either way, if
>>a packager has failed to allow pg_upgrade to be usable within his
>>package set(s), it's a packaging error that you should complain
>>about.
>>
>>
>
> The problem of pg_upgrade is that it needed to hold two set of databases
> data in the server.
> This is not be desirable (very slow) or possible (space limitation) for
> database with huge data.
I don't really find that to be a problem. I think most people will
argue that it's better not to mess with the original database during
the upgrade process for safety purposes. Storage is cheap and getting
cheaper.
merlin