On Wed, Jun 14, 2017 at 1:01 AM, Bruce Momjian <br...@momjian.us> wrote: > On Mon, Jun 12, 2017 at 06:31:11PM +0300, Vladimir Borodin wrote: >> What about the following sequence? >> >> 1. Run pg_upgrade on master, >> 2. Start it in single-user mode and stop (to get right wal_level in >> pg_control), >> 3. Copy pg_control somewhere, >> 4. Start master, run analyze and stop. >> 5. Put the control file from step 3 to replicas and rsync them according to >> the >> documentation. >> >> And I think that step 10.f in the documentation [1] should be fixed to >> mention >> starting in single-user mode or with disabled autovacuum. >> >> [1] https://www.postgresql.org/docs/devel/static/pgupgrade.html > > First, I want to apologize for not getting involved in this thread > earlier, and I want to thank everyone for the huge amount of detective > work in finding the cause of this bug. > > Let me see if I can replay how the standby server upgrade instructions > evolved over time. > > Initially we knew that we had to set wal_level to replica+ so that when > you reconnect to the standby servers, the WAL would have the right > contents. (We are basically simulating pg_start/stop backup with > rsync.) > > There was a desire to have those instructions inside a documentation > block dedicated to standby server upgrades, so the wal_level adjustment > and new server start/stop was added to that block. I assumed a > start/stop could not modify the WAL, or at least nothing important would > happen, but obviously I was wrong. (pg_upgrade takes steps to ensure > that nothing happens.) Adding ANALYZE in there just made it worse, but > the problem always existed. I sure hope others haven't had a problem > with this. > > Now, it seems we later added a doc section early on that talks about > "Verify standby servers" so I have moved the wal_level section into that > block, which should be safe. There is now no need to start/stop the new > server since pg_upgrade will do that safely already. >
! <para> ! Also, if upgrading standby servers, change <varname>wal_level</> ! to <literal>replica</> in the <filename>postgresql.conf</> file on ! the new cluster. I think it is better to indicate that this is required for the master cluster (probably it is clear for users) /"on the new cluster."/"on the new master cluster.". Do we need something different for v10 where default wal_level is 'replica' -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers