Re: Major upgrade of PostgreSQL and MySQL - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Major upgrade of PostgreSQL and MySQL
Date
Msg-id CAHyXU0wY52tYs=jBLidyHajMxcRYbm6Sqq5WkiJ-QgG_SC9RRg@mail.gmail.com
Whole thread Raw
In response to Re: Major upgrade of PostgreSQL and MySQL  (Patrick Dung <patrick_dkt@yahoo.com.hk>)
List pgsql-general
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


pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: Major upgrade of PostgreSQL and MySQL
Next
From: Stephen Frost
Date:
Subject: Re: Major upgrade of PostgreSQL and MySQL