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
example:
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
$ 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:
http://www.postgresql.org/mailpref/pgsql-hackers
