From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Andreas Joseph Krogh <andreas@visena.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: Thu, 14 Sep 2017 22:09:42 -0400
Message-ID: <20170915020942.GM4628@tamriel.snowman.net> (raw)
In-Reply-To: <CAB7nPqS9=TdARzpSLrrqQcDAQfhbtGJ5UbqMh017V=dKRwGWeQ@mail.gmail.com>
References: <20170914191356.GC6595@momjian.us>
<VisenaEmail.db.e5ceedc56ec1471.15e82123988@tc7-visena>
<CAB7nPqS9pL7qwRu8ku8byvYYZOEHHXzUAgSJRbP7AENtHT8E_A@mail.gmail.com>
<20170915012124.GI4628@tamriel.snowman.net>
<CAB7nPqS9=TdARzpSLrrqQcDAQfhbtGJ5UbqMh017V=dKRwGWeQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Michael,
* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Fri, Sep 15, 2017 at 10:21 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > No, one of the baseline requirements of pg_upgrade is to *not* screw
> > with the existing cluster. Removing its WAL or "cleaning it up"
> > definitely seems like it's violating that principle.
>
> Not necessarily. Using --link it is game over for rollback once the
> new cluster has started.
Yes, but not *before* the new cluster has started.
> My reference to clean up the contents of
> pg_xlog refers to the moment the new cluster has been started.
Alright, that's technically beyond the scope of pg_upgrade then...
> This
> could be achieved with a pre-upgrade flag present on-disk that the
> startup process looks at to perform actions needed. This flag of
> course needs to depend on the version of the binary used to start
> Postgres, and is written by pg_upgrade itself which links the new
> cluster's pg_wal into the location of the old cluster. In short, if an
> upgrade to PG version N is done, and that the flag related to the
> cleanup of N is found, then actions happen. If Postgres is started
> with a binary version N-1, nothing happens, and existing flags are
> cleaned up. What I am not sure is if such extra machinery is worth
> doing as things can be saved by just moving the soft link position of
> the cluster after running pg_upgrade and before starting the new
> cluster.
Ugh. That strikes me as far more complication than would be good for
this..
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
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: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, michael.paquier@gmail.com, andreas@visena.com, bruce@momjian.us, robertmhaas@gmail.com
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
In-Reply-To: <20170915020942.GM4628@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox