Merlin Moncure <mmonc...@gmail.com> wrote:

> Takahiro<itagaki.takah...@oss.ntt.co.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: dblink.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to