| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Chad Trabant <chad(at)iris(dot)washington(dot)edu> |
| Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Upgrade and re-synchronization with logical replication (pglogical and PG 10) |
| Date: | 2018-01-25 17:01:36 |
| Message-ID: | f885db59-a800-2d8d-0fcf-5b15a363b4c3@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On 1/24/18 21:06, Chad Trabant wrote:
>> On Jan 23, 2018, at 9:36 AM, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-01-25 17:02:39 | Re: Postgres for hadoop |
| Previous Message | Laurenz Albe | 2018-01-25 16:37:37 | Re: Check for logical / physical corruption |