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