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