Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Andreas Joseph Krogh <andreas(at)visena(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: 2017-09-15 02:09:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Fri, Sep 15, 2017 at 10:21 AM, Stephen Frost <sfrost(at)snowman(dot)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



In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-09-15 02:16:22 Re: path toward faster partition pruning
Previous Message David Rowley 2017-09-15 01:55:25 Re: path toward faster partition pruning