Re: pg_upgrade and logical replication

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade and logical replication
Date: 2023-02-28 02:25:48
Message-ID: 20230228022548.zuzqyu33dbv5ppyx@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2023-02-28 02:31:47 Re: Non-superuser subscription owners
Previous Message Masahiko Sawada 2023-02-28 02:16:45 Re: Should vacuum process config file reload more often