Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1db6MK-0000tA-R8 for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Jul 2017 14:35:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1db6MI-0006QW-Sj for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Jul 2017 14:35:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1db6MH-0006OB-4y for pgsql-hackers@postgresql.org; Fri, 28 Jul 2017 14:35:17 +0000 Received: from post.visena.com ([46.226.10.50]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1db6MD-0005Yr-Vl for pgsql-hackers@postgresql.org; Fri, 28 Jul 2017 14:35:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=visena.com; s=20141101.wh; h=Content-Type:MIME-Version:Subject:Message-ID:To:From:Date; bh=TZQ2WDt/X1JjTrBHfEg3fJVErXnUHbsuPhuksMjlRGA=; b=XL/NqF6wlSiTQMAwzWaxziU6DQV3VbF/0xKNmiqRy83+3jCSX91USby7qotNCqkAKvPDOApvFOw1Xh6zUTOOp9AVw2AefZU3Y1NGAOmMC/Fpv09RncRL2egRRfLrobTFTFwkI9+e+Wg8vcn1GFUae+8072fq8im64Jsh1Ps4Tkc=; Received: from [10.0.1.10] (helo=tc7-visena.wh.internal.visena.com) by post.visena.com with esmtp (Exim 4.82) (envelope-from ) id 1db6M9-0003lJ-1l for pgsql-hackers@postgresql.org; Fri, 28 Jul 2017 16:35:11 +0200 Received: from localhost ([127.0.0.1] helo=tc7-visena.wh.internal.visena.com) by tc7-visena.wh.internal.visena.com with esmtp (Exim 4.86_2) (envelope-from ) id 1db6M9-0003lo-0s for pgsql-hackers@postgresql.org; Fri, 28 Jul 2017 16:35:09 +0200 Date: Fri, 28 Jul 2017 16:35:08 +0200 (CEST) From: Andreas Joseph Krogh To: pgsql-hackers@postgresql.org Message-ID: Subject: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers) MIME-Version: 1.0 X-Mailer: Visena Mail 2.1.0-SNAPSHOT X-Spam-Score: -1.0 X-Spam-Report: SpamAssasin (score=-1.0, required 5.0 ALL_TRUSTED=-1,HTML_MESSAGE=0.001) Content-Type: multipart/alternative; boundary="----=_Part_77_1040031328.1501252508938" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org ------=_Part_75_27070484.1501252508928 Content-Type: multipart/related; boundary="----=_Part_76_238465399.1501252508928" ------=_Part_76_238465399.1501252508928 Content-Type: multipart/alternative; boundary="----=_Part_77_1040031328.1501252508938" ------=_Part_77_1040031328.1501252508938 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi -hackers. =C2=A0 I'm reading https://www.postgresql.org/docs/10/static/pgupgrade.html=C2=A0t= o try to=20 understand how to upgrade standby-servers using pg_upgrade with pg10. =C2=A0 The text in step 10 sais: "You will not be running pg_upgrade on the standby servers, but rather rsyn= c",=20 which to me sounds like rsync, in step 10-f, should be issued on the standy= =20 servers. Is this the case? If so I don't understand how the standby's data = is=20 upgraded and what "remote_dir" is. If rsync is supposed to be issued on the= =20 primary then I think it should be explicitly mentioned, and step 10-f shoul= d=20 provide a clarer example with more detailed values for the directory-struct= ures=20 involved. =C2=A0 I really think section 10 needs improvement as I'm certainly not comfortabl= e=20 upgrading standbys following the existing procedure. =C2=A0 Thanks. =C2=A0 -- Andreas Joseph Krogh ------=_Part_77_1040031328.1501252508938 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi -hackers.
=C2=A0
I'm reading https://www.postgresql.org/docs/10/static/pgupgrade.html= =C2=A0to try to understand how to upgrade standby-servers using pg_upgrade = with pg10.
=C2=A0
The text in step 10 sais:
"You will not be running pg_upgrade on the standby servers, but r= ather rsync", which to me sounds like rsync, in step 10-f, should be i= ssued on the standy servers. Is this the case? If so I don't understand how= the standby's data is upgraded and what "remote_dir" is. If rsyn= c is supposed to be issued on the primary then I think it should be explici= tly mentioned, and step 10-f should provide a clarer example with more deta= iled values for the directory-structures involved.
=C2=A0
I really think section 10 needs improvement as I'm certainly not comfo= rtable upgrading standbys following the existing procedure.
=C2=A0
Thanks.
=C2=A0
--
Andreas Joseph Krogh
------=_Part_77_1040031328.1501252508938-- ------=_Part_76_238465399.1501252508928-- ------=_Part_75_27070484.1501252508928--