Re: pg_upgrade and logical replication - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pg_upgrade and logical replication
Date
Msg-id 20230228022548.zuzqyu33dbv5ppyx@jrouhaud
Whole thread Raw
In response to Re: pg_upgrade and logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pg_upgrade and logical replication
List pgsql-hackers
On Mon, Feb 27, 2023 at 03:39:18PM +0530, Amit Kapila wrote:
>
> BTW, thinking some more
> on this, how will we allow to continue replication after upgrading the
> publisher? During upgrade, we don't retain slots, so the replication
> won't continue. I think after upgrading subscriber-node, user will
> need to upgrade the publisher as well.

The scenario I'm interested in is to rely on logical replication only for the
upgrade, so the end state (and start state) is to go back to physical
replication.  In that case, I would just create new physical replica from the
pg_upgrade'd server and failover to that node, or rsync the previous publisher
node to make it a physical replica.

But even if you want to only rely on logical replication, I'm not sure why you
would want to keep the publisher node as a publisher node?  I think that doing
it this way will lead to a longer downtime compared to doing a failover on the
pg_upgrade'd node, make it a publisher and then move the former publisher node
to a subscriber.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Should vacuum process config file reload more often
Next
From: Stephen Frost
Date:
Subject: Re: Non-superuser subscription owners