MIME-Version: 1.0
References: 
 <CA+3i_M-fFb4cZ4SYToBft5VERvo0AZ22LRfzLE5axpGr9YsgPg@mail.gmail.com>
 <CALdSSPhuCN_cS7MXobWx7Lh0adc-NWd8M115QMGC+yf21kCgNg@mail.gmail.com>
In-Reply-To: 
 <CALdSSPhuCN_cS7MXobWx7Lh0adc-NWd8M115QMGC+yf21kCgNg@mail.gmail.com>
From: Lakshmi N <lakshmin.jhs@gmail.com>
Date: Sun, 15 Mar 2026 11:22:16 -0700
Message-ID: 
 <CA+3i_M9ySDQ4WbEiPC5qxzi30mkaLbK+dbDOxYTSqRR3fGWZ1g@mail.gmail.com>
Subject: Re: Add missing CHECK_FOR_INTERRUPTS calls in dblink module
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000003d0b97064d142fb2"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2B3i_M9ySDQ4WbEiPC5qxzi30mkaLbK%2BdbDOxYTSqRR3fGWZ1g%40mail.gmail.com>
Precedence: bulk

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

Hi Kirill,

Apologies for the delay in responding.

On Tue, Mar 10, 2026 at 2:25=E2=80=AFAM Kirill Reshke <reshkekirill@gmail.c=
om>
wrote:

>
> Hi!
> Are you trying to fix any real problem? So, do you have any reproduces
> where dblink stucks while processing tuples? I am somehow surprised if
> we do not have CFI somewhere inside tuplestore_puttuple...
>

This can be reproduced when iteration over millions of tuples, particularly
when the tuples spill to a temp file on disk.
I added pg_usleep(1000L) before the end of the loop to have a
predictable repro, which looks like no CFI in tuplestore_puttuple.
Tested with the below queries to verify the behavior (which should trigger
temp IO).

SET work_mem =3D '64kB';
SELECT dblink_connect('myconn', 'dbname=3D' || current_database());
SELECT dblink_open('myconn', 'mycursor', 'SELECT i, repeat(''x'', 1024)
FROM generate_series(1, 100000) i');
explain analyze SELECT * FROM dblink_fetch('myconn', 'mycursor', 100000) AS
t(i int, pad text);
SELECT dblink_close('myconn', 'mycursor');
SELECT dblink_disconnect('myconn');
RESET work_mem;

Regards,
Lakshmi

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Kirill,<div><br></div><div>Apologies f=
or the delay in responding.</div></div><br><div class=3D"gmail_quote gmail_=
quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 10, 2026=
 at 2:25=E2=80=AFAM Kirill Reshke &lt;<a href=3D"mailto:reshkekirill@gmail.=
com">reshkekirill@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><br>
Hi!<br>
Are you trying to fix any real problem? So, do you have any reproduces<br>
where dblink stucks while processing tuples? I am somehow surprised if<br>
we do not have CFI somewhere inside tuplestore_puttuple...<br></blockquote>=
<div><br></div><div>This can be reproduced when iteration over millions of =
tuples, particularly when the tuples spill to a temp file on disk.</div><di=
v>I added pg_usleep(1000L) before the end of the loop to have a predictable=
=C2=A0repro, which looks=C2=A0like no CFI in tuplestore_puttuple.</div><div=
>Tested with the below queries to verify the behavior (which should trigger=
 temp IO).</div><div><br></div><div>SET work_mem =3D &#39;64kB&#39;;<br>SEL=
ECT dblink_connect(&#39;myconn&#39;, &#39;dbname=3D&#39; || current_databas=
e());<br>SELECT dblink_open(&#39;myconn&#39;, &#39;mycursor&#39;, &#39;SELE=
CT i, repeat(&#39;&#39;x&#39;&#39;, 1024) FROM generate_series(1, 100000) i=
&#39;);<br>explain analyze SELECT * FROM dblink_fetch(&#39;myconn&#39;, =
9;mycursor&#39;, 100000) AS t(i int, pad text);<br>SELECT dblink_close(&#39=
;myconn&#39;, &#39;mycursor&#39;);<br>SELECT dblink_disconnect(&#39;myconn&=
#39;);<br>RESET work_mem;</div><div><br></div><div>Regards,</div><div>Laksh=
mi</div><div><br></div><div><br></div></div></div>

--0000000000003d0b97064d142fb2--