Re: walreceiver is uninterruptible on win32

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Fri, Apr 2, 2010 at 17:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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