On Thu, Mar 2, 2023 at 4:21 PM Julien Rouhaud <rjuju...@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.
