Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 27 Sep 2023 12:44:38 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
	Julien Rouhaud <rjuju123@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade and logical replication
Message-ID: <ZROlJo8p2ACv5HmD@paquier.xyz>
References: 
 <CALDaNm1ZrbHaWpJwwNhDTJocRKWd3rEkgJazuDdZ9Z-WdvonFg@mail.gmail.com>
 <TYAPR01MB5866F1BA00D86EA7EA134348F5F1A@TYAPR01MB5866.jpnprd01.prod.outlook.com>
 <CALDaNm1JzqTreCUrhNu5E1gq7Q8r_u3+FrisyT7moOED=UdoCg@mail.gmail.com>
 <CAA4eK1+J0Ki74WScoTC4mJSYn4mSOhgrRFcFMQ_OCV0bfXjWVg@mail.gmail.com>
 <ZQt7ixloBQbl0FZF@paquier.xyz>
 <CAA4eK1+b+hZLKhehCU-=MuYrxzniKkytUR+7nWhBV2RnoBx91w@mail.gmail.com>
 <ZQzMbWtE8S5LUjIZ@paquier.xyz>
 <CAA4eK1KTV4UXhwfe-hPSwccdWKBu1+QVh-whJLomW1bdhV8jYQ@mail.gmail.com>
 <ZRElFZSb_0clJiLG@paquier.xyz>
 <CAA4eK1+QV_qsUUef1bsOTE3AeB6jEdCspJhT4QCsVkHjudEC-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Nv1M2X4RyyVqv5B/"
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1+QV_qsUUef1bsOTE3AeB6jEdCspJhT4QCsVkHjudEC-A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZROlJo8p2ACv5HmD%40paquier.xyz>
Precedence: bulk


--Nv1M2X4RyyVqv5B/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 26, 2023 at 09:40:48AM +0530, Amit Kapila wrote:
> On Mon, Sep 25, 2023 at 11:43=E2=80=AFAM Michael Paquier <michael@paquier=
=2Exyz> wrote:
>> Sure, that's assuming that the publisher side is upgraded.
>=20
> 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?
>>
>=20
> 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

--Nv1M2X4RyyVqv5B/
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUTpSYACgkQnvQgOdby
QH1HNw/9HJ9joKgyVXPcngiuxhmR1+3mp+l0yLK90KAm0KoEMNRmTJFYKshNMWNT
jIkyTScO0e42BpnnqEaw7/DMtaquf4K2E181D27JIzNu9MxVquBwZl6sPajUOqCy
TctpwIY/XkV2z1bgVzxp5FZ/CeglL26ndMFjyJ/Gvq2yZTSr1rgXxV9Mkm3HF1lx
rq+SFg21MIbO4/W/8tn4GVPY3o0b9vcvPrxi8BuOk1cqvYGXaghMdWXmrctWNnQg
nPWGn2anXp1QLD07pd9DLumsib2LnO2I2spndmKMjVI5S/2INQ+4I6AYraUu9I+M
DBpGuTvutpYS5GE4sYr4gs9cQ2AP8o9n7pcKZU6Xy8iaVoQFjUZhlTGRojk6udHq
WZ660cKMJFj6HlCq0ISxowbaxYOdwTyvLU3x7qn6nHTbxcOCVruc2O16aVlsnmOd
ZmYQT6AlYTBudplvTt0qx35dhYkdYlHGrhO11b14W+p1aCcFXFfc/KQZNCRwX7Tq
QJ2JxwGiVUPIbcGRi06mA/GtCOyyatXTm7M5dx+6f2Eubucvo2/4gQmOfWbCaoXT
vUkFWXsIJjjLGO+KKQXcDxwnMsCg4nrWulXAJJ6W/sieS27gPgmwQgIBLZW3yLIf
mhPeHVcSXRnNnSfGmIrpFJNYxDPZQCGunGLW7fKOsC4xcrtyFdo=
=ip09
-----END PGP SIGNATURE-----

--Nv1M2X4RyyVqv5B/--