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.
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 |