On Wed, Jun 14, 2017 at 07:45:17PM +0530, Amit Kapila wrote: > > 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'
You know, I thought about that and was afraid saying "new master cluster" would be confusing because it isn't a master _yet_, but if you feel it will help, and I considered it, let's add it. The problem is that in the old instructions, at the point we were mentioning this, it was the new master, which is why I evaluated removing it in the first place. (Yeah, I am amazed I considered all these cases.) Updated patch attached. Thanks. -- 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 +
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml new file mode 100644 index bf58a0a..05fa053 *** a/doc/src/sgml/ref/pgupgrade.sgml --- b/doc/src/sgml/ref/pgupgrade.sgml *************** NET STOP postgresql-9.0 *** 317,331 **** </step> <step> ! <title>Verify standby servers</title> <para> ! If you are upgrading Streaming Replication and Log-Shipping standby ! servers, verify that the old standby servers are caught up by running ! <application>pg_controldata</> against the old primary and standby ! clusters. Verify that the <quote>Latest checkpoint location</> ! values match in all clusters. (There will be a mismatch if old ! standby servers were shut down before the old primary.) </para> </step> --- 317,338 ---- </step> <step> ! <title>Prepare for standby server upgrades</title> <para> ! If you are upgrading standby servers (as outlined in section <xref ! linkend="pgupgrade-step-replicas">), verify that the old standby ! servers are caught up by running <application>pg_controldata</> ! against the old primary and standby clusters. Verify that the ! <quote>Latest checkpoint location</> values match in all clusters. ! (There will be a mismatch if old standby servers were shut down ! before the old primary.) ! </para> ! ! <para> ! Also, if upgrading standby servers, change <varname>wal_level</> ! to <literal>replica</> in the <filename>postgresql.conf</> file on ! the new master cluster. </para> </step> *************** pg_upgrade.exe *** 410,416 **** </para> </step> ! <step> <title>Upgrade Streaming Replication and Log-Shipping standby servers</title> <para> --- 417,423 ---- </para> </step> ! <step id="pgupgrade-step-replicas"> <title>Upgrade Streaming Replication and Log-Shipping standby servers</title> <para> *************** pg_upgrade.exe *** 471,486 **** </para> </step> - <step> - <title>Start and stop the new master cluster</title> - - <para> - In the new master cluster, change <varname>wal_level</> to - <literal>replica</> in the <filename>postgresql.conf</> file - and then start and stop the cluster. - </para> - </step> - <step> <title>Run <application>rsync</></title> --- 478,483 ----
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers