Re: lost replication slots after pg_upgrade

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

In response to

Browse pgsql-hackers by date

  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