Re: Add missing CHECK_FOR_INTERRUPTS calls in dblink module

From: Lakshmi N <lakshmin(dot)jhs(at)gmail(dot)com>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add missing CHECK_FOR_INTERRUPTS calls in dblink module
Date: 2026-03-15 18:22:16
Message-ID: CA+3i_M9ySDQ4WbEiPC5qxzi30mkaLbK+dbDOxYTSqRR3fGWZ1g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kirill,

Apologies for the delay in responding.

On Tue, Mar 10, 2026 at 2:25 AM Kirill Reshke <reshkekirill(at)gmail(dot)com>
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 = '64kB';
SELECT dblink_connect('myconn', 'dbname=' || 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2026-03-15 18:52:24 Re: Supporting non-deterministic collations with tailoring rules.
Previous Message Andrey Borodin 2026-03-15 17:53:14 Re: Compress prune/freeze records with Delta Frame of Reference algorithm