From: Bruce Momjian <bruce@momjian.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Vladimir Borodin <root@simply.name>
Cc: Dmitriy Sarafannikov <dsarafannikov@yandex.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Broken hint bits (freeze)
Date: Wed, 14 Jun 2017 11:14:09 -0400
Message-ID: <20170614151409.GD4750@momjian.us> (raw)
In-Reply-To: <CAA4eK1JTYJ8etByswMstXVOt+qTT8WT5uMGj=O-r5PbB30kt3A@mail.gmail.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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 +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackersAttachments:
[text/x-diff] hintbits.diff (2.4K, ../20170614151409.GD4750@momjian.us/2-hintbits.diff)
download | inline diff:diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgmlnew file mode 100644index 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 ----
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, amit.kapila16@gmail.com, root@simply.name, dsarafannikov@yandex.ru
Subject: Re: Broken hint bits (freeze)
In-Reply-To: <20170614151409.GD4750@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox