public inbox for [email protected]
help / color / mirror / Atom feedFrom: Glyn Astill <[email protected]>
To: Tory M Blue <[email protected]>
To: Jim Nasby <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Clarification on using pg_upgrade
Date: Wed, 15 Jun 2016 10:14:27 +0000 (UTC)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEaSS0Z=p8e5DVw+K3N4rBc5WcoaOVBULKNjtUMmcejb_r15ZA@mail.gmail.com>
References: <CAEaSS0atiPVYLhMSwtzcZB5efeTxYjYDR1s3OZSshpkAY1VsAg@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAEaSS0bi0oAk2u615P-WmtLj3XfvAeBBLgO05nxyK5tD7Pui5Q@mail.gmail.com>
<[email protected]>
<CAEaSS0Z-0eNY2Qhc8D5ywdRFxadHEhAZkEuYOeZCKxfOt142Mg@mail.gmail.com>
<[email protected]>
<CAEaSS0Z=p8e5DVw+K3N4rBc5WcoaOVBULKNjtUMmcejb_r15ZA@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-performance>
----- Original Message -----
> From: Tory M Blue <[email protected]>
> To: Jim Nasby <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Sent: Tuesday, 14 June 2016, 22:08
> Subject: Re: [PERFORM] Clarification on using pg_upgrade
>
> Right, that's what we do, but then to upgrade, we have to drop/add the
> node, because it's being upgraded. If I'm updating the underlying OS,
> I have to kill it all. If I'm doing a postgres upgrade, using an old
> version of slon, without using pg_upgrade, I have to drop the db,
> recreate it, which requires a drop/add.
>
> I'm trying to figure out how to best do it using pg_upgrade instead
> of the entire drop/add for postgres upgrades (which are needed if you
> are using slon as an upgrade engine for your db).
>
I've just skimmed through this thread, but I can't quite gather what it is you're trying to achieve. Are you looking to move away from Slony? Upgrade by any means with or without Slony? Or just find a "fast" way of doing a major upgrade whilst keeping Slony in-place as your replication method?
If it's the latter, the easiest way is to have 2 or more subscribers subscribed to the same sets and one at a time; drop a subscriber node, upgrade and re-initdb, then use clone node to recreate it from another subscriber. If you're intent on using pg_upgrade you might be able to fudge it as long as you can bump up current txid to be greater than what it was before the upgrade; in fact I've done similar before with a slony subscriber, but only as a test on a small database.
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Clarification on using pg_upgrade
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox