Re: query cancel issues in contrib/dblink

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: query cancel issues in contrib/dblink
Date: 2009-06-26 14:00:20
Message-ID: b42b73150906260700h5d09593fx18afb1f9524329a5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 25, 2009 at 10:41 PM, Itagaki
Takahiro<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> Hi,
>
> contrib/dblink seems to have no treatments for query cancels.
> It causes the following issues:
>
> (1) Users need to wait for completion of remote query.
>    Requests for query cancel won't be delivered to remote servers.
>
> (2) PGresult objects will be memory leak. The result is not released
>    when query is cancelled; it is released only when dblink function
>    is called max_calls times.
>
> They are long standing issues (not only in 8.4),
> but I hope we will fix them to make dblink more robust.
>
> 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?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-06-26 14:13:34 Re: Proposal: More portable way to support 64bit platforms
Previous Message Tom Lane 2009-06-26 13:41:07 Re: [PATCH] backend: compare word-at-a-time in bcTruelen