Magnus Hagander <mag...@hagander.net> writes: > On Fri, Apr 2, 2010 at 17:26, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers