On Fri, Jun 16, 2017 at 04:33:16AM +0300, Sergey Burladyan wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > !     <para>
> > !      Also, if upgrading standby servers, change <varname>wal_level</>
> > !      to <literal>replica</> in the <filename>postgresql.conf</> file on
> > !      the new cluster.
> >       </para>
> >      </step>
> I am not sure how this help.
> wal_level is reset by pg_resetxlog during pg_upgrade, so it does not
> depend on postgresql.conf. After pg_upgrade wal_level always is
> 'minimal', that is why you must start and stop new master before rsync:
> ==== output ====
> $ "$bin"/pg_controldata "$ver" | grep wal_level
> wal_level setting:                    replica
> $ "$bin"/pg_resetwal "$ver"
> Write-ahead log reset
> $ "$bin"/pg_controldata "$ver" | grep wal_level
> wal_level setting:                    minimal
> ================

Yes, I see that, but pg_resetxlog is run _before_ the _new_ cluster is
started for the last time, so in my testing the wal_level at the end of
pg_upgrade matches the value in postgresql.conf, e.g. "replica".  For

        Upgrade Complete
        Optimizer statistics are not transferred by pg_upgrade so,
        once you start the new server, consider running:
        Running this script will delete the old cluster's data files:

        $ pg_controldata /u/pg/data/ | grep wal_level
        wal_level setting:                    replica

The way pg_upgrade uses rsync, the standby never needs to replay the WAL
when it starts up because we already copied the changed system tables
and hard linked the user data files.

  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to