Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsBjF-0001Kq-45 for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Sep 2017 17:45:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dsBjE-0003LI-MD for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Sep 2017 17:45:36 +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 ) id 1dsBhe-0000YX-Rq for pgsql-hackers@postgresql.org; Wed, 13 Sep 2017 17:43:58 +0000 Received: from mout.gmx.net ([212.227.15.15]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dsBhb-0002VQ-JP for pgsql-hackers@postgresql.org; Wed, 13 Sep 2017 17:43:58 +0000 Received: from nighthawk.chemicalconnection.dyndns.org ([88.217.114.236]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M0y8F-1dZopk3wjP-00v9Dd; Wed, 13 Sep 2017 19:43:36 +0200 Received: from mbanck by nighthawk.chemicalconnection.dyndns.org with local (Exim 4.84_2) (envelope-from ) id 1dsBdL-0003u3-NU; Wed, 13 Sep 2017 19:39:31 +0200 Date: Wed, 13 Sep 2017 19:39:31 +0200 From: Michael Banck To: Stephen Frost Cc: Bruce Momjian , Andreas Joseph Krogh , Michael Paquier , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers) Message-ID: <20170913173931.GA12194@nighthawk.caipicrew.dd-dns.de> References: <20170912215202.GA6766@momjian.us> <20170912230020.GD6766@momjian.us> <20170912233840.GS4628@tamriel.snowman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170912233840.GS4628@tamriel.snowman.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:8yCW9WYB48vq2UT4vhnOMkZLfzcbbmvLQn6QekpVt5J83A/G013 zTJi9OYpV3CuUqJ3AdV9epnpcsiOWGsc7OsenmDjnryRzfB9Q36LeUk0arRi45n1hyBLDcy nWIBBMltL7YbkZuzDHors/3PQgqEsz8s/rvdA2KCZtG6zC71UFPB3rl7P+2+zWDg8U2rhOV d2mwSSngxWh1aWlq0CkpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2o50fTLT45A=:wXkHwwPaDk4Wn+rEiUmETz OtW0rb6JQH7m55h4DLHlw1ORCCRd0B/EnL5aPguipLS2NiI5RqKqU+3Bcz/7Up9+WfFe7pxWt 2UU2tlxybQf4nqywSAAnCFC7ARz7oPlnZqN/dA9dOE74488IfQozAjQ16LG7mDrGVUMlISARD uo4wl7F5l0+Y2i8KYr5UNWyysUUyba7LlsN3RK6rBsLLLCfV5Al54PRAL8S5f1DhV0c+D0e5c aUANYMMGt2W5uf8WGDIvKKKKZf35sFZUhcebS8/cpxf5qfVuAzbsrAKxxkUeVjZt5kck+vG9h ukFVF8q8RGBNeYV6Ectl3z214NdHGVdOSbYRT8bYSCVmlqpYI5EV8AqXcsUpHgCAvpYFagtVI UgQbnMSWk29E9mQk9jRJ+G9jr0FFrVctJOa60IOE96689AsDccJ5Lxl/l53vJ92plKH14Qthy 3sw/gExBc0gtV7Qgsn6i+GSVgAFs3SNFnCWGCEWWJ6CJ2dIhBpLfrpGQ/6cduAPDTlxywqWXc Mi5gmnSvo2QrQsDn9wMHonujgPzvIQNVue+Vxk7gx+udZgL/EEIPYvla0XbwMW38opQZ06u3j R8lhuu9IDLCkAh9gJZ0ZGqUPxhmH/d6pBaHMz64fjtpq8xuKg0K6+XgGZjCI8rSSevtym/JsW 5rtqhP1uXVqsf0K7sAoBLZIFZj6lqBhNP7pr0jxys9U2qS/YOIBAODHb7YzxYnRiPIhg2C09e 79g7q1jHJ1H3rzz0uqvk4OsKIqqO/WGaMqx3Fehn/3G4+zHTiwrITuNG3Q89ToWUjPZ9Ds82d 7BRE1aLFWybpud1xbKtJzWFYzTh/g== 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 On Tue, Sep 12, 2017 at 07:38:40PM -0400, Stephen Frost wrote: > Further, really, I think we should provide a utility to do all of the > above instead of using rsync- and that utility should do some additional > things, such as: > > - Check that the control file on the primary and replica show that they > reached the same point prior to the pg_upgrade. If they didn't, then > things could go badly as there's unplayed WAL that the primary got > through and the replica didn't. > > - Not copy over unlogged data, or any other information that shouldn't > be copied across. > > - Allow the directory structures to be more different between the > primary and the replica than rsync allows (wouldn't have to have a > common subdirectory on the replica). > > - Perhaps other validation checks or similar. > > Unfortunately, this is a bit annoying as it necessairly involves running > things on both the primary and the replica from the same tool, without > access to PG, meaning we'd have to work through something else (such as > SSH, like rsync does, but then what would we do for Windows...?). Maybe pg_rewind's mechanism could be partially reused for this as it seems to accomplish something vaguely similar AIUI? Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers