Re: walreceiver is uninterruptible on win32

On Mon, Mar 15, 2010 at 10:14, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Wed, Mar 10, 2010 at 10:09, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> Hi,
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
>>> On win32, the blocking libpq functions like PQconnectdb() and
>>> PQexec() are uninterruptible since they use the vanilla select()
>>> instead of our signal emulation layer compatible select().
>>> Nevertheless, currently walreceiver uses them to establish a
>>> connection, send a handshake message and wait for the reply.
>>> So walreceiver also becomes uninterruptible for a while. This
>>> is the must-fix problem for 9.0.
>>>
>>> I replaced the blocking libpq functions currently used with
>>> asynchronous ones, and used the emulated version of select()
>>> to wait, to make walreceiver interruptible. Here is the patch.
>>
>> These are issues that affect other things running libpq in the backend
>> as well, right? Such as dblink?
>
> Yes. So Heikki wrote the patch for dblink.
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02072.php

IIRC that was never applied.

>
>> Perhaps we can factor out most of this
>> into functions in backend/port/win32 so that we can re-use it fro
>> there?
>
> Sorry. I couldn't get your point. Could you explain it in detail?

What I'm referring to is the part that Heikki writes as "The
implementation should be shared between the two, but I'm not sure
how". I think we should try to factor out things that can be shared
into separate functions and stick those in port/win32 (assuming
they're win32-specific, otherwise, in another suitable location), and
then call them from both. There seems to be a lot of things that
should be doable that way.

I notice for example that the dblink patch doesn't have the code for
timeout handling - shouldn't it?

I think we need to look at this as a single problem needing to be
solved, and then have the same solution applied to dblink and
walreceiver.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/