| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Major upgrade of PostgreSQL and MySQL |
| Date: | 2013-09-13 13:58:48 |
| Message-ID: | 1023.1379080728@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Ivan Voras (ivoras(at)freebsd(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Travers | 2013-09-13 14:30:40 | Re: Best way to populate nested composite type from JSON` |
| Previous Message | Merlin Moncure | 2013-09-13 13:37:08 | Re: Best way to populate nested composite type from JSON` |