On Tue, Sep 26, 2023 at 09:40:48AM +0530, Amit Kapila wrote: > On Mon, Sep 25, 2023 at 11:43 AM Michael Paquier <mich...@paquier.xyz> wrote: >> Sure, that's assuming that the publisher side is upgraded. > > At some point, user needs to upgrade publisher and subscriber could > itself have some publications defined which means the downstream > subscribers will have the same problem.
Not always. I take it as a valid case that one may want to create a logical setup only for the sake of an upgrade, and trashes the publisher after a failover to an upgraded subscriber node after the latter has done a sync up of the data that's been added to the relations tracked by the publications while the subscriber was pg_upgrade'd. >>> This is the primary reason why I prioritized to work on the publisher >>> side before getting this patch done, otherwise, the solution for this >>> patch was relatively clear. I am not sure but I guess this could be >>> the reason why originally we left it in the current state, otherwise, >>> restoring subscription rel's or origin doesn't seem to be too much of >>> an additional effort than what we are doing now. >> >> By "additional effort", you are referring to what the patch is doing, >> with the binary dump of pg_subscription_rel, right? >> > > Yes. Okay. I'd like to move on with this stuff, then. At least it helps in maintaining data integrity when doing an upgrade with a logical setup. The patch still needs more polishing, though.. -- Michael
signature.asc
Description: PGP signature
