Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M329645=pgsql-hackers-arkari@postgresql.org>)
	id 1dL9zs-0006hT-Py
	for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Jun 2017 15:14:16 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M329645=pgsql-hackers-arkari@postgresql.org>)
	id 1dL9zs-0007CS-BQ
	for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Jun 2017 15:14:16 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <bruce@momjian.us>)
	id 1dL9zr-0007CJ-Qn
	for pgsql-hackers@postgresql.org; Wed, 14 Jun 2017 15:14:15 +0000
Received: from momjian.us ([72.94.173.45])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.84_2)
	(envelope-from <bruce@momjian.us>)
	id 1dL9zo-0008Ua-C5
	for pgsql-hackers@postgresql.org; Wed, 14 Jun 2017 15:14:15 +0000
Received: from bruce by momjian.us with local (Exim 4.84_2)
	(envelope-from <bruce@momjian.us>)
	id 1dL9zl-0000cM-W3; Wed, 14 Jun 2017 11:14:09 -0400
Date: Wed, 14 Jun 2017 11:14:09 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Vladimir Borodin <root@simply.name>,
	Dmitriy Sarafannikov <dsarafannikov@yandex.ru>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Broken hint bits (freeze)
Message-ID: <20170614151409.GD4750@momjian.us>
References: 
 <CAA4eK1KtEDAKbq_40hSYBTgvTf88Jio4Q_DxiEK0dkjjXdg4_g@mail.gmail.com>
 <4C1127FC-74AE-4544-9B22-6A32FD0C0607@yandex.ru>
 <CAA4eK1L4WKBs5LQ52hZ_whrR=A-cQwsXvGwbaz7k6O3NYUjhKQ@mail.gmail.com>
 <948C9927-CC63-47F7-87B9-1FA5921E6D4A@yandex.ru>
 <CAA4eK1LqGRcSQJ0SF_JDECjbc=YTMxQLuQzq7-dm006TDN5J=A@mail.gmail.com>
 <0DFC2046-3025-465E-BBB8-1E55479A9B7D@simply.name>
 <CAA4eK1Lyk6_B5oV7VDw7vMmroubVoKXy4Fw6eJ6W-mfwwPpXdQ@mail.gmail.com>
 <C4ADB713-CF88-4A75-A3C3-10E4E0A750DB@simply.name>
 <20170613193124.GQ13873@momjian.us>
 <CAA4eK1JTYJ8etByswMstXVOt+qTT8WT5uMGj=O-r5PbB30kt3A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1JTYJ8etByswMstXVOt+qTT8WT5uMGj=O-r5PbB30kt3A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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  <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 +

--HcAYCG3uE/tztfnV
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="hintbits.diff"

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 ----

--HcAYCG3uE/tztfnV
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--HcAYCG3uE/tztfnV--