Re: [HACKERS] Broken hint bits (freeze)

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 +