Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ee2VH-0003ck-8F for pgsql-admin@arkaria.postgresql.org; Tue, 23 Jan 2018 17:36:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ee2VG-0001we-PI for pgsql-admin@arkaria.postgresql.org; Tue, 23 Jan 2018 17:36:58 +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 1ee2VG-0001wU-7h for pgsql-admin@lists.postgresql.org; Tue, 23 Jan 2018 17:36:58 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ee2V8-0002IC-AK for pgsql-admin@lists.postgresql.org; Tue, 23 Jan 2018 17:36:56 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 12FA921058; Tue, 23 Jan 2018 12:36:49 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 23 Jan 2018 12:36:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=A2Pn6Z g1btWB6GtmFwfEQCezHSgj/USViekW1k7GCtc=; b=cKoHmxg+vcDUuyw6hxqehZ 3+FRAoCJPm7IgQ1e39CW2zVbjCOv4KYFS0g43EoJ41Hb3whzuxQOVOBzfGzjGSgi 8HoWFQsCaay2plDlFbkiK3cnGVXsWWIQeWrwE/GpNioF2lJUmv9y/lFW3Ypuw5ZP SNVxcBicOnMiXci9O1idl6rPHCzFmZjj94q4ccec5/saSCE2/sq1s0a9cSXkWsyg KcpTND2woZvmsjYSwcPiZvHMjxxCQbJPVVw9xVyBD2bDaYNGNrdrWpFTZVSuNpob d8g5RSw8/X/Cpv6ce2N2dnIFcoS1Chhmaan4bySYZ9Xe2ryR0SoikhfanU4hl0Rw == X-ME-Sender: Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id BF6F27E2E5; Tue, 23 Jan 2018 12:36:48 -0500 (EST) Subject: Re: Upgrade and re-synchronization with logical replication (pglogical and PG 10) To: Chad Trabant , pgsql-admin@lists.postgresql.org References: <10358935-0D5B-4C94-AF02-D64B1A195442@iris.washington.edu> From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Tue, 23 Jan 2018 12:36:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <10358935-0D5B-4C94-AF02-D64B1A195442@iris.washington.edu> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 1/22/18 01:53, Chad Trabant wrote: > 1) In my initial testing it seems that an upgrade via pg_upgrade does > not migrate logical replication slots or origins > (pg_replication_slots and pg_replication_origin). Correct. A better approach might be to use pglogical itself to do the upgrade. That is, set up a new replica somewhere that is PG10, replicate into that, and switch over. > 2) pglogical has mechanisms to re-synchronize an entire subscription or > selected tables.  After identifying a few tables, out of many, that are > out of sync following the re-construction of a replication link, I have > used this capability to re-synchronize just what was needed. Short of > completely re-building logical replication links (clearing and copying > all the data) does postgres 10 have any mechanisms to re-synchronize a > subscription or a subset thereof? Not officially, but you could perhaps achieve that by manually fiddling with the entries in the system catalog pg_subscription_rel. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services