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>
 <CAD21AoBEBqQONiZxvnUYOu814yB2tRPrmX=7KqvL+f3ae7250w@mail.gmail.com>
 <CALj2ACUenekLgjMr8x4DyuU=zKZ4eNqW9XF-1PovSctkY2VA0Q@mail.gmail.com>
 <CAFC+b6pO44=zGqwijzrcyGGTYCM51Y7zS5uQX0_nWjsxW9i3QQ@mail.gmail.com>
 <CALj2ACU=A31kqHELyaF-=2vnyed=cO2JNQt+vY92KtHLF-m8sg@mail.gmail.com>
 <CAD21AoB4MsTpG5JEkifght_tQ91VHJO_8kpsDCrG-z9qkkmN5g@mail.gmail.com>
 <CALj2ACVGpVHuqchPPFWdiLDN-PDPCEe=sU43YB7nqafE+VMXaQ@mail.gmail.com>
 <CAD21AoB61CgA921J2FwXzxfxUsxQzi7GYAZaH05PHmb6HFe_hg@mail.gmail.com>
 <CALj2ACV724Yr2=5Jun4XGQyGhvCiXo+7GXJUnybqf9SYqQA6gw@mail.gmail.com>
 <CALj2ACXR=5SoApm6duEOc6pi=-KaBqSxuSP6XNQot2LywrqtAA@mail.gmail.com>
 <CAD21AoABTzYoe99gmdvs4D8kwfD=AtaaWFb8C2biMkUncmcXDA@mail.gmail.com>
 <CALj2ACV6jYzaMZD3jF3nTj_bLoUZw8+UwucVKTK1kVCwXYVQ8w@mail.gmail.com>
 <CAD21AoArh6-RfOGGY6GfWqqHv0qUJEMwXVmGQk=29uYiKFLSgA@mail.gmail.com>
 <CALj2ACV_PV5LiL55O02UYJ_zfZw0CUKnR_nW83mpm0ZuYkbM8g@mail.gmail.com>
In-Reply-To: 
 <CALj2ACV_PV5LiL55O02UYJ_zfZw0CUKnR_nW83mpm0ZuYkbM8g@mail.gmail.com>
From: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Date: Tue, 7 Apr 2026 20:09:45 +0530
Message-ID: 
 <CAFC+b6qOmhz9tEpPNrD5U1XGBWmVSHu6OoKoA-ZuGE=UkOVTEQ@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>,
	SATYANARAYANA NARLAPURAM <satyanarlapuram@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="000000000000e223ce064edfc16f"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFC%2Bb6qOmhz9tEpPNrD5U1XGBWmVSHu6OoKoA-ZuGE%3DUkOVTEQ%40mail.gmail.com>
Precedence: bulk

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

Hi,

On Mon, Apr 6, 2026 at 11:12=E2=80=AFPM Bharath Rupireddy <
bharath.rupireddyforpostgres@gmail.com> wrote:

> Hi,
>
> On Mon, Apr 6, 2026 at 1:45=E2=80=AFAM Masahiko Sawada <sawada.mshk@gmail=
.com>
> wrote:
> >
> > > I took a look at the v10 patch and it LGTM. I tested it - make
> > > check-world passes, pgindent doesn't complain.
> >
> > While reviewing the patch, I found that with this patch, backend
> > processes and autovacuum workers can simultaneously attempt to
> > invalidate the same slot for the same reason. When invalidating a
> > slot, we send a signal to the process owning the slot and wait for it
> > to exit and release the slot. If the process takes a long time to exit
> > for some reason, subsequent autovacuum workers attempting to
> > invalidate the same slot will also send a SIGTERM and get stuck at
> > InvalidatePossiblyObsoleteSlot(). In the worst case, this could result
> > in all autovacuum activity being blocked. I think we need to address
> > this problem.
>
> Thank you!
>
> You're right that multiple autovacuum workers can wait on the same
> slot for SIGTERM to take effect on the process (mainly walsenders)
> holding the slot. Once the process holding the slot exits, one worker
> finishes the invalidation and the others see it's done and move on.
>
> However, IMHO, this is unlikely to be a problem in practice.
>

I was able to reproduce this using pg_recvlogical on a slot, by pausing the
walsender using debugger , then i did some hacky stuff around the GUCs
(just to test), but in production IIUC I think During decoding a large
transaction
or network delay , the walsender gets stuck for "some" time, so backend and
autovacuum workers get stuck until then, after that they resume their work,
Correct me if I am wrong :)

If needed, we could add a flag to skip extra invalidation attempts
> based on field experience.
>

+1, yeah this would help other backends or autovacuum workers not
to retry again the same invalidation and stuck , instead they can check
the flag and be assured that slot invalidation is being taken care of,
so others can move on.


--=20
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 6, 2=
026 at 11:12=E2=80=AFPM Bharath Rupireddy &lt;<a href=3D"mailto:bharath.rup=
ireddyforpostgres@gmail.com">bharath.rupireddyforpostgres@gmail.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-left:1ex">Hi,<br>
<br>
On Mon, Apr 6, 2026 at 1:45=E2=80=AFAM Masahiko Sawada &lt;<a href=3D"mailt=
o:sawada.mshk@gmail.com" target=3D"_blank">sawada.mshk@gmail.com</a>&gt; wr=
ote:<br>
&gt;<br>
&gt; &gt; I took a look at the v10 patch and it LGTM. I tested it - make<br=
>
&gt; &gt; check-world passes, pgindent doesn&#39;t complain.<br>
&gt;<br>
&gt; While reviewing the patch, I found that with this patch, backend<br>
&gt; processes and autovacuum workers can simultaneously attempt to<br>
&gt; invalidate the same slot for the same reason. When invalidating a<br>
&gt; slot, we send a signal to the process owning the slot and wait for it<=
br>
&gt; to exit and release the slot. If the process takes a long time to exit=
<br>
&gt; for some reason, subsequent autovacuum workers attempting to<br>
&gt; invalidate the same slot will also send a SIGTERM and get stuck at<br>
&gt; InvalidatePossiblyObsoleteSlot(). In the worst case, this could result=
<br>
&gt; in all autovacuum activity being blocked. I think we need to address<b=
r>
&gt; this problem.<br>
<br>
Thank you!<br>
<br>
You&#39;re right that multiple autovacuum workers can wait on the same<br>
slot for SIGTERM to take effect on the process (mainly walsenders)<br>
holding the slot. Once the process holding the slot exits, one worker<br>
finishes the invalidation and the others see it&#39;s done and move on.<br>
<br>
However, IMHO, this is unlikely to be a problem in practice.<br></blockquot=
e><div>=C2=A0<br>I was able to reproduce this using pg_recvlogical on a slo=
t, by pausing the</div><div>walsender using debugger , then i did some hack=
y stuff around the GUCs<br>(just to test), but in production IIUC I think D=
uring decoding a large transaction<br>or network delay , the walsender gets=
 stuck for &quot;some&quot; time, so backend and<br>autovacuum workers get =
stuck until then, after that they resume their work,<br>Correct me if I am =
wrong :)<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If =
needed, we could add a flag to skip extra invalidation attempts<br>
based on field experience.<br></blockquote><div><br>+1, yeah this would hel=
p other backends or autovacuum workers not<br>to retry again the same inval=
idation and stuck , instead they can check<br>the flag and be assured that =
slot invalidation is being taken care of,<br>so others can move on.</div></=
div><div><br clear=3D"all"></div><div><br></div><span class=3D"gmail_signat=
ure_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div d=
ir=3D"ltr"><span style=3D"color:rgb(34,34,34)">Thanks,</span><br style=3D"c=
olor:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">Srinath Reddy Sadip=
iralla</span><br style=3D"color:rgb(34,34,34)"><span style=3D"color:rgb(34,=
34,34)">EDB:=C2=A0</span><a href=3D"https://www.enterprisedb.com/" style=3D=
"color:rgb(17,85,204)" target=3D"_blank">https://www.enterprisedb.com/</a><=
/div></div></div>

--000000000000e223ce064edfc16f--