Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 29 Sep 2023 09:33:59 +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: <ZRYbdzsSlAp9bnR3@paquier.xyz>
References: 
 <TYAPR01MB586682CF17623F6E71B9D3ADF59D9@TYAPR01MB5866.jpnprd01.prod.outlook.com>
 <20230424072224.qd3awkfrjcanw2pa@jrouhaud>
 <TYAPR01MB5866FE3A990CAE1FFA3F1472F56A9@TYAPR01MB5866.jpnprd01.prod.outlook.com>
 <CALDaNm1ZrbHaWpJwwNhDTJocRKWd3rEkgJazuDdZ9Z-WdvonFg@mail.gmail.com>
 <TYAPR01MB5866F1BA00D86EA7EA134348F5F1A@TYAPR01MB5866.jpnprd01.prod.outlook.com>
 <CALDaNm1JzqTreCUrhNu5E1gq7Q8r_u3+FrisyT7moOED=UdoCg@mail.gmail.com>
 <CAA4eK1+J0Ki74WScoTC4mJSYn4mSOhgrRFcFMQ_OCV0bfXjWVg@mail.gmail.com>
 <CALDaNm3QgD17nNVmdPtTfP+J5F_UfGqC9n40c+X+RV9VAfWa-Q@mail.gmail.com>
 <CALDaNm2sdoTu=nsfEE9+WyXiYBYrE5bE2s6xi9zmqheqsLaNXg@mail.gmail.com>
 <CAA4eK1+gQEesHUHcncDixjUdEVF1e=Ymu_z-CLj1yyRoMc1bwA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="zSysXCOMQiPDK3LG"
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1+gQEesHUHcncDixjUdEVF1e=Ymu_z-CLj1yyRoMc1bwA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZRYbdzsSlAp9bnR3%40paquier.xyz>
Precedence: bulk


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

On Wed, Sep 27, 2023 at 07:31:41PM +0530, Amit Kapila wrote:
> On Wed, Sep 27, 2023 at 3:37=E2=80=AFPM vignesh C <vignesh21@gmail.com> w=
rote:
>> Once the table is in SUBREL_STATE_SYNCDONE state, the apply worker
>> will check if the apply worker has some LSN records that need to be
>> applied to reach the LSN of the table. Once the required WAL is
>> applied, the table state will be changed from SUBREL_STATE_SYNCDONE to
>> SUBREL_STATE_READY state. Since there is a chance that in this case
>> the apply worker has to apply some transactions to get all the tables
>> in READY state, I felt the minimum requirement should be that at least
>> all the tables should be in READY state for the upgradation of the
>> Subscriber.
>=20
> I don't think this theory is completely correct because the pending
> WAL can be applied even after an upgrade.

Yeah, agreed that putting a pre-check about the state of the relations
stored in pg_subscription_rel when handling the upgrade of a
subscriber is not necessary.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUWG3cACgkQnvQgOdby
QH0EHBAAn2RJp+jSS5ewb51tXqdmhc8f0Ccu4oy7xSrIlnLOYPWy3ByFaOwjSd73
lC2ClfSXzJwtn+Y6JFYpaY2T3OlUXHyl18teFxTEh4cSOCMF3DNy1e2P+CraofmZ
FHn1hbKdkFe+ihheCD3idrr1tM5mo/qY221nfOjwujyex5pYKMVv/f9wMvUFglVr
t0kTPQXUjH30fHAIMyaDwm8j2lKEKNm8Ix4kRdPdB6kR6eOXv76ZN0JybqK6JyQ7
0VLOWJcd+oPUn18G3ABcX3ARNaeJnOWHyuSgBP5J+uNuCytTy3vkl14vBPhVylaA
uiCw/Rb9Wq3Vbui7n0t5rnt3zrSimRIY6DVY0PR1t7PJV0byo3pFwx8TkUGiBTIn
XYlAa3c0iOXV1dFeKf4mfV98vj+Mc43WXyoY8137RxDaAEoWMgWQVkD5H7Uo2cBU
DfnOuFVeesp5hc89ZPd904z9/GQpBw66dMUHDPUW7+D1HgW8s81GqxsaHP4kijKv
n3MiCy7vfOVHSdGzGYruhF+14/VWGY759jLRf7pcE0454yRk3ngv1W1GaShNNxIq
37yJh9gn5qyrw/CnTwkqMs39cpPtu98p8fiyO8gFYl95/BTcJjhd5yG+5eVOCEKD
dX26arqILDPRpFucDEbgrXf6xPzjj5l+ksIyIul4AWAYdgYGs0U=
=7yj6
-----END PGP SIGNATURE-----

--zSysXCOMQiPDK3LG--