| 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: | Whole Thread | Raw Message | 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 |