From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Subject: | Re: query cancel issues in contrib/dblink |
Date: | 2009-06-29 03:42:16 |
Message-ID: | 20090629123230.AD52.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Takahiro<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> > contrib/dblink seems to have no treatments for query cancels.
> > (1) Users need to wait for completion of remote query.
> > (2) PGresult objects will be memory leak.
Here is a patch to fix the issues. I hope the fixes will be ported
to older versions if possible.
(1) is fixed by using non-blocking APIs in libpq. I think we should
always use non-blocking APIs even if the dblink function itself is
a blocking-function.
(2) is fixed by RegisterXactCallback(AtEOXact_dblink). However, there
might be any better solutions -- for example, ResourceOwner framework.
> > For (1), asynchronous libpq functions should be used instead of blocking
> > ones, and wait for the remote query using a loop with CHECK_FOR_INTERRUPTS().
>
> How would you structure this loop exactly?
Please check execute_query() and wait_for_result() in the patch.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
dblink.patch | application/octet-stream | 6.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-06-29 06:53:25 | Re: Query progress indication - an implementation |
Previous Message | Robert Haas | 2009-06-29 02:41:57 | Re: dependencies for generated header files |