Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Apr 2, 2010 at 17:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I disapprove of the whole approach, actually. �The right way to fix this
>> is to not touch or replace libpq at all, but to change walreceiver to
>> use libpq's async-query facilities directly. �Instead of PQexec, use
>> PQsendQuery and then a loop involving PQisBusy, PQgetResult, etc.
>> You've more or less done that loop, but you've put it in the wrong
>> place.
> Any particular reason not to wrap that in a function? Not called
> pgwin32_PQexec() then, but something more generic? And not doing any
> #defines to change PQexec, but call that wrapper directly?
Yeah, that's fine. I just think it's easier to deal with this as a
local issue in walreceiver and dblink than to try to pretend we're
changing libpq's API.
>> The larger point is that I don't believe this issue exists only on
>> Windows. �I think we're going to want something like this on all
>> platforms, and that implies supporting poll() not just select() for the
>> waiting part.
> The most important part of the issue doesn't (because PQexec will be
> interrupted by a signal), but there may certainly be others.
Really? As you pointed out yourself, if control doesn't reach a
CHECK_FOR_INTERRUPTS then we have a problem. We also know that select
isn't interrupted by signals on all platforms.
regards, tom lane
