MIME-Version: 1.0
References: 
 <CAFPTHDa5aP8ixTZBygGAe48E1N=DvuPzcXikw7bNKixLMN3pVg@mail.gmail.com>
 <OS9PR01MB12149E188221BED862E4BE9E0F5342@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <CALDaNm2-uwpbJ8fnrssp+hORvOutsqRoZAsa05xVVzXe5Bt3bw@mail.gmail.com>
 <CAFPTHDaNLRqPAda1RUDVfSDH7eLTaONv0UEmc9H5sdMW1Li2Bg@mail.gmail.com>
 <CAN4CZFOb3urMsLPsEyVrYR7-7yA+BC5kDgQQd0nAQ8xj2zyRcA@mail.gmail.com>
 <CAFPTHDYqpuZ6o2-HuCJDYqJ7GY3+zV+Xo-gT7PAgi4Bkz+oTxw@mail.gmail.com>
 <CAN4CZFN4oLdxLwUXHUPV-5mFmK+4dcnppP00fV3i4qmMYCAkGA@mail.gmail.com>
 <CAFPTHDbBiTfjYkQwYTNA2a4LRp8Sp7_zB59fmV0R7977ztxgmg@mail.gmail.com>
 <CAFPTHDaftSwzGTGbFEw8rwDBsub0XqcDm1wxQcquj-Y3PC2qrg@mail.gmail.com>
 <CANhcyEVercsNbgC5CTkMNzh_w_Jv1uK7RQg9vEvAeNQhoBHCKQ@mail.gmail.com>
 <CAJpy0uAXynzWr4w_9GkJC3i=LL9WsRCZYVWAV0PgKmgs8riWzg@mail.gmail.com>
 <CAFPTHDavPyxsWjK0cRO3yOaP4u8FGYrOJuXJB-4wzneAY3H3Ug@mail.gmail.com>
 <CANhcyEVFSutXXdt_0XMCD37NE7Yd7ROdDVEE06D8YVyPNEBFHg@mail.gmail.com>
 <CANhcyEVd7eDKGtsrUqwZO5McTG4dsJ+X8OxO31Xgu6sWmo--hw@mail.gmail.com>
 <CAFPTHDbyVt_ggdi+rOP4=jBmgU=DDgYWuLxc4oQ6ux-T0H-ZBg@mail.gmail.com>
In-Reply-To: 
 <CAFPTHDbyVt_ggdi+rOP4=jBmgU=DDgYWuLxc4oQ6ux-T0H-ZBg@mail.gmail.com>
From: Rui Zhao <zhaorui126@gmail.com>
Date: Mon, 22 Jun 2026 00:22:14 +0800
Message-ID: 
 <CAHWVJhGoi+2bzZDNxtnB8Xc+DuFKB=YvqC0Xoc_HfzcgHAwMUg@mail.gmail.com>
Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
To: Ajin Cherian <itsajin@gmail.com>
Cc: Shlok Kyal <shlok.kyal.oss@gmail.com>,
 shveta malik <shveta.malik@gmail.com>,
	Zsolt Parragi <zsolt.parragi@percona.com>, vignesh C <vignesh21@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 shveta malik <shvetamalik@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000075c9480654c5ee0e"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHWVJhGoi%2B2bzZDNxtnB8Xc%2BDuFKB%3DYvqC0Xoc_HfzcgHAwMUg%40mail.gmail.com>
Precedence: bulk

--00000000000075c9480654c5ee0e
Content-Type: text/plain; charset="UTF-8"

>
> Hi Ajin,
>
> Thanks for v8. A couple of comments:
>
> 1) The PG17 gating seems inconsistent between the dump and the check now.
> dumpReplicationOrigins() is called unconditionally:
>
>     if (binary_upgrade && archDumpFormat == archNull)
>         dumpReplicationOrigins(conn);
>
> but get_subscription_info(), which sets nrepl_origins, is still only
> called for old clusters >= 17 in check_new_cluster():
>
>     if (GET_MAJOR_VERSION(old_cluster.major_version) >= 1700)
>         ...
>         get_subscription_info(&old_cluster);
>
> and check_new_cluster_replication_origins() returns early on it:
>
>     if (old_cluster.nrepl_origins == 0)
>         return;
>
> For a < 17 old cluster get_subscription_info() is never called, so
> nrepl_origins stays 0 and this returns early. So when such a cluster has a
> (user-created) origin, the origin still gets dumped and recreated, while
> the "new cluster must have no origins" and max_active_replication_origins
> checks are skipped, and the upgrade fails during restore instead of at the
> check step. nrepl_origins is just a count(*) on pg_replication_origin, so
> moving its collection out of the >= 1700 block should be enough.
>
> 2) 004_subscription.pl only checks subscription origins (pg_<oid>). Since
> the patch migrates all origins, should we also create a user origin
> (pg_replication_origin_create()) and verify its roident/remote_lsn after
> the upgrade? That would also cover the case in (1).
>
> Thanks,
> Rui
>

--00000000000075c9480654c5ee0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Hi Ajin,<br><br>Thanks for v8. A c=
ouple of comments:<br><br>1) The PG17 gating seems inconsistent between the=
 dump and the check now.<br>dumpReplicationOrigins() is called unconditiona=
lly:<br><br>=C2=A0 =C2=A0 if (binary_upgrade &amp;&amp; archDumpFormat =3D=
=3D archNull)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 dumpReplicationOrigins(conn);<=
br><br>but get_subscription_info(), which sets nrepl_origins, is still only=
<br>called for old clusters &gt;=3D 17 in check_new_cluster():<br><br>=C2=
=A0 =C2=A0 if (GET_MAJOR_VERSION(old_cluster.major_version) &gt;=3D 1700)<b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 get_subscr=
iption_info(&amp;old_cluster);<br><br>and check_new_cluster_replication_ori=
gins() returns early on it:<br><br>=C2=A0 =C2=A0 if (old_cluster.nrepl_orig=
ins =3D=3D 0)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;<br><br>For a &lt; 17 o=
ld cluster get_subscription_info() is never called, so<br>nrepl_origins sta=
ys 0 and this returns early. So when such a cluster has a<br>(user-created)=
 origin, the origin still gets dumped and recreated, while<br>the &quot;new=
 cluster must have no origins&quot; and max_active_replication_origins<br>c=
hecks are skipped, and the upgrade fails during restore instead of at the<b=
r>check step. nrepl_origins is just a count(*) on pg_replication_origin, so=
<br>moving its collection out of the &gt;=3D 1700 block should be enough.<b=
r><br>2) <a href=3D"http://004_subscription.pl">004_subscription.pl</a> onl=
y checks subscription origins (pg_&lt;oid&gt;). Since<br>the patch migrates=
 all origins, should we also create a user origin<br>(pg_replication_origin=
_create()) and verify its roident/remote_lsn after<br>the upgrade? That wou=
ld also cover the case in (1).<br><br>Thanks,<br>Rui<br>
</blockquote></div></div>

--00000000000075c9480654c5ee0e--