MIME-Version: 1.0
References: 
 <CA+-JvFsMHckBMzsu5Ov9HCG3AFbMh056hHy1FiXazBRtZ9pFBg@mail.gmail.com>
 <OSCPR01MB149667506BCFD684FEFDCB919F511A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CALj2ACUmPbkcj4y4oeXvzUkBejG68QDtrFF7QHDC_qz2vQcTCg@mail.gmail.com>
 <CAHg+QDfnK7tQxsEZox=kOkYfqANmL70mwn0N=eRrJxE1Z+1ygg@mail.gmail.com>
 <CALj2ACX_o+dKeAaK76mpAtG646UnDHpGUWziUkCvicVz8mz6=A@mail.gmail.com>
 <CAD21AoATM=Un8ejnbcDQ7q+CaCoxpkA7Ln9bacvQEoymqvjPug@mail.gmail.com>
 <CALj2ACUmUb=CLEyfsQrW0WAkF6Y9fiBfG6pnPjepfOM7A1XReA@mail.gmail.com>
 <CAD21AoAg6x57a8LoP2s+0vgizp9QGHcLGJL9bwh7kzEJq3arBg@mail.gmail.com>
 <CALj2ACWcaSkfMAQu3s6ZkTZuoFvVRD=DkxXbBwC33PL9+kzsqw@mail.gmail.com>
In-Reply-To: 
 <CALj2ACWcaSkfMAQu3s6ZkTZuoFvVRD=DkxXbBwC33PL9+kzsqw@mail.gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Thu, 26 Mar 2026 02:48:42 -0700
Message-ID: 
 <CAHg+QDeYLUo9HBWRHnSE1s5NDs6XJqP_QMNf14BpK1HzEh_uGQ@mail.gmail.com>
Subject: Re: Introduce XID age based replication slot invalidation
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 John H <johnhyvr@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000e39160064dea4ab5"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHg%2BQDeYLUo9HBWRHnSE1s5NDs6XJqP_QMNf14BpK1HzEh_uGQ%40mail.gmail.com>
Precedence: bulk

--000000000000e39160064dea4ab5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 25, 2026 at 12:17=E2=80=AFPM Bharath Rupireddy <
bharath.rupireddyforpostgres@gmail.com> wrote:

> Hi,
>
> On Tue, Mar 24, 2026 at 11:50=E2=80=AFPM Masahiko Sawada <sawada.mshk@gma=
il.com>
> wrote:
> >
> > > Please find the v3 patch for further review.
> >
> > Thank you for updating the patch. I think the patch is reasonably
> > simple and can avoid unnecessary overheads well due to XID-based
> > checks. Here are some comments:
>
> Thank you for reviewing the patch.
>
> > vacuum_get_cutoff() is also called by VACUUM FULL, CLUSTER, and
> > REPACK. I'm not sure that users would expect the slot invalidation
> > also in these commands. I think it's better to leave
> > vacuum_get_cutoff() a pure cutoff computation function and we can try
> > to invalidate slots in heap_vacuum_rel(). It requires additional
> > ReadNextTransactionId() but we can live with it, or we can make
> > vacuum_get_cutoffs() return the nextXID as well (stored in *cutoffs).
>
> +1. I chose to perform the slot invalidation in heap_vacuum_rel by
> getting the next txn ID and calling vacuum_get_cutoffs again when a
> slot gets invalidated. IMHO, this is simple than adding a flag and do
> the invalidation selectively in vacuum_get_cutoffs.
>
> >   if (TransactionIdPrecedes(oldestXmin, cutoffXID))
> > +   {
> > +       invalidated =3D
> InvalidateObsoleteReplicationSlots(RS_INVAL_XID_AGE,
> > +                                                        0,
> > +                                                        InvalidOid,
> > +
> InvalidTransactionId,
> > +                                                        nextXID);
> > +   }
> >
> > I think it's better to check the procArray->replication_slot_xmin and
> > procArray->replication_slot_catalog_xmin before iterating over each
> > slot. Otherwise, we would end up checking every slot even when a long
> > running transaction holds the oldestxmin back.
>
> +1. Changed.
>
> > +   if (!TransactionIdIsNormal(cutoffXID))
> > +       cutoffXID =3D FirstNormalTransactionId;
> >
> > These codes have the same comment but are doing a slightly different
> > thing. I guess the latter is missing '-'?
>
> Fixed the typo.
>
> I fixed a test error being reported in CI.
>
> Please find the attached v4 patch for further review.
>

 InvalidateObsoleteReplicationSlots(uint32 possible_causes,
    XLogSegNo oldestSegno, Oid dboid,
-   TransactionId snapshotConflictHorizon)
+   TransactionId snapshotConflictHorizon, TransactionId nextXID)

May be add TransactionId nextXID in a new line?

Thinking loud, vacuum doesn't  run on a hot_standby, that means this GUC is
not applicable for hot_standby. Is this intended? Why not call during
checkpoint/restorepoint itself like other slot invalidation checks?

Thanks,
Satya

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 25, 2026=
 at 12:17=E2=80=AFPM Bharath Rupireddy &lt;<a href=3D"mailto:bharath.rupire=
ddyforpostgres@gmail.com" target=3D"_blank">bharath.rupireddyforpostgres@gm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">Hi,<br>
<br>
On Tue, Mar 24, 2026 at 11:50=E2=80=AFPM Masahiko Sawada &lt;<a href=3D"mai=
lto:sawada.mshk@gmail.com" target=3D"_blank">sawada.mshk@gmail.com</a>&gt; =
wrote:<br>
&gt;<br>
&gt; &gt; Please find the v3 patch for further review.<br>
&gt;<br>
&gt; Thank you for updating the patch. I think the patch is reasonably<br>
&gt; simple and can avoid unnecessary overheads well due to XID-based<br>
&gt; checks. Here are some comments:<br>
<br>
Thank you for reviewing the patch.<br>
<br>
&gt; vacuum_get_cutoff() is also called by VACUUM FULL, CLUSTER, and<br>
&gt; REPACK. I&#39;m not sure that users would expect the slot invalidation=
<br>
&gt; also in these commands. I think it&#39;s better to leave<br>
&gt; vacuum_get_cutoff() a pure cutoff computation function and we can try<=
br>
&gt; to invalidate slots in heap_vacuum_rel(). It requires additional<br>
&gt; ReadNextTransactionId() but we can live with it, or we can make<br>
&gt; vacuum_get_cutoffs() return the nextXID as well (stored in *cutoffs).<=
br>
<br>
+1. I chose to perform the slot invalidation in heap_vacuum_rel by<br>
getting the next txn ID and calling vacuum_get_cutoffs again when a<br>
slot gets invalidated. IMHO, this is simple than adding a flag and do<br>
the invalidation selectively in vacuum_get_cutoffs.<br>
<br>
&gt;=C2=A0 =C2=A0if (TransactionIdPrecedes(oldestXmin, cutoffXID))<br>
&gt; +=C2=A0 =C2=A0{<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0invalidated =3D InvalidateObsoleteReplicat=
ionSlots(RS_INVAL_XID_AGE,<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 InvalidOid,<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 InvalidTransactionId,<=
br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nextXID);<br>
&gt; +=C2=A0 =C2=A0}<br>
&gt;<br>
&gt; I think it&#39;s better to check the procArray-&gt;replication_slot_xm=
in and<br>
&gt; procArray-&gt;replication_slot_catalog_xmin before iterating over each=
<br>
&gt; slot. Otherwise, we would end up checking every slot even when a long<=
br>
&gt; running transaction holds the oldestxmin back.<br>
<br>
+1. Changed.<br>
<br>
&gt; +=C2=A0 =C2=A0if (!TransactionIdIsNormal(cutoffXID))<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0cutoffXID =3D FirstNormalTransactionId;<br=
>
&gt;<br>
&gt; These codes have the same comment but are doing a slightly different<b=
r>
&gt; thing. I guess the latter is missing &#39;-&#39;?<br>
<br>
Fixed the typo.<br>
<br>
I fixed a test error being reported in CI.<br>
<br>
Please find the attached v4 patch for further review.<br></blockquote><div>=
<br></div><div>=C2=A0InvalidateObsoleteReplicationSlots(uint32 possible_cau=
ses,<br>=C2=A0								 =C2=A0 XLogSegNo oldestSegno, Oid dboid,<br>-							=
	 =C2=A0 TransactionId snapshotConflictHorizon)<br>+								 =C2=A0 Transac=
tionId snapshotConflictHorizon, TransactionId nextXID)</div><div><br></div>=
<div>May be add=C2=A0TransactionId nextXID in a new line?</div><div><br></d=
iv><div>Thinking loud, vacuum doesn&#39;t=C2=A0 run on a hot_standby, that =
means this GUC is not applicable for hot_standby. Is this intended? Why not=
 call during checkpoint/restorepoint itself like other slot invalidation ch=
ecks?=C2=A0</div><div><br></div><div>Thanks,</div><div>Satya</div></div></d=
iv>
</div>

--000000000000e39160064dea4ab5--