From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: lost replication slots after pg_upgrade |
Date: | 2020-10-13 21:37:18 |
Message-ID: | 20201013213718.GH24889@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 13, 2020 at 11:34:27PM +0200, Peter Eisentraut wrote:
> On 2020-10-13 19:23, Pavel Stehule wrote:
> > no, I just missi note, so after upgrade by pg_upgrade I have to recreate
> > replication slots. Some like
> >
> > after pg_upgrade you should to do:
> >
> > a) run analyze .... (it is a known case)
> > b) recreate replication slots - these slots are not removed in the
> > upgrade process.
>
> An argument could be made that pg_upgrade should copy over logical
> replication slots. The normal scenario would be that you pause your logical
> subscriptions, run pg_upgrade on the publisher, then un-pause the
> subscriptions. The subscribers then ought to be able to reconnect and
> continue consuming logical changes. Since the content of the publisher
> database is logically the same before and after the upgrade, this should
> appear transparent to the subscribers. They'll just see that the publisher
> was offline for a while.
I guess that is possible since pg_upgrade resets the WAL location,
though not the WAL contents.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2020-10-13 21:42:32 | Re: gs_group_1 crashing on 13beta2/s390x |
Previous Message | Peter Eisentraut | 2020-10-13 21:34:27 | Re: lost replication slots after pg_upgrade |