On Fri, Jun 16, 2017 at 04:33:16AM +0300, Sergey Burladyan wrote:
> Bruce Momjian <bruce@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
example:
Upgrade Complete----------------Optimizer statistics are not transferred by pg_upgrade so,once you start the new
server,consider running: ./analyze_new_cluster.shRunning this script will delete the old cluster's data files:
./delete_old_cluster.sh
$ pg_controldata /u/pg/data/ | grep wal_levelwal_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 <bruce@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 +