Subject: Re: Upgrade and re-synchronization with logical replication
 (pglogical and PG 10)
To: Chad Trabant <chad@iris.washington.edu>
References: <10358935-0D5B-4C94-AF02-D64B1A195442@iris.washington.edu>
 <e508c847-bf4e-5121-27d4-30e6d0a4bd48@2ndquadrant.com>
 <E03760D6-22CD-448F-BBD5-747D91971DED@iris.washington.edu>
Cc: pgsql-admin@lists.postgresql.org
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <f885db59-a800-2d8d-0fcf-5b15a363b4c3@2ndquadrant.com>
Date: Thu, 25 Jan 2018 12:01:36 -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: <E03760D6-22CD-448F-BBD5-747D91971DED@iris.washington.edu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 1/24/18 21:06, Chad Trabant wrote:
>> On Jan 23, 2018, at 9:36 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>>
>> 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.
> 
> Thank you for confirming.  I'm sure there is a good reason for this, can someone explain why (even if briefly)?

pg_upgrade does not preserve WAL information such as LSNs between the
old and new cluster, so it wouldn't know where the slots should start.
Basically, the approach that pg_upgrade takes is incompatible with
replication slots.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services