On Thu, Mar 2, 2023 at 4:21 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Thu, Mar 02, 2023 at 03:47:53PM +0530, Amit Kapila wrote:
> >
> > Why don't we try to support the direct upgrade of logical replication
> > nodes? Have you tried to analyze what are the obstacles and whether we
> > can have solutions for those? For example, one of the challenges is to
> > support the upgrade of slots, can we copy (from the old cluster) and
> > recreate them in the new cluster by resetting LSNs? We can also reset
> > origins during the upgrade of subscribers and recommend to first
> > upgrade the subscriber node.
>
> I'm not sure I get your question. This whole thread is about direct upgrade of
> logical replication nodes, at least the subscribers, and what is currently
> preventing it.
>
It is only about subscribers and nothing about publishers.
> For the publisher nodes, that may be something nice to support (I'm assuming it
> could be useful for more complex replication setups) but I'm not interested in
> that at the moment as my goal is to reduce downtime for major upgrade of
> physical replica, thus *not* doing pg_upgrade of the primary node, whether
> physical or logical. I don't see why it couldn't be done later on, if/when
> someone has a use case for it.
>
I thought there is value if we provide a way to upgrade both publisher
and subscriber. Now, you came up with a use case linking it to a
physical replica where allowing an upgrade of only subscriber nodes is
useful. It is possible that users find your steps easy to perform and
didn't find them error-prone but it may be better to get some
authentication of the same. I haven't yet analyzed all the steps in
detail but let's see what others think.
--
With Regards,
Amit Kapila.
