| 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
| 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 |