2010/1/17 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> Magnus Hagander wrote:
>> Which shows one potentially big problem - since we're calling select()
>> from inside libpq, it's not calling our "signal emulation layer
>> compatible select()". This means that at this point, walreceiver is
>> not interruptible. Which also shows itself if I shut down the system -
>> the walreceiver stays around, and won't terminate properly. Do we need
>> to invent a way for libpq to call back into backend code to do this
>> select? We certainly can't have libipq use our version directly -
>> since that would break all non-postmaster/postgres processes.
>
> Hmm, contrib/dblink probably has the same issue then.
Yes.
> We could replace the blocking PQexec() calls with PQsendQuery(), and use
> the emulated version of select() to wait.
Hmm. That would at least theoretically work, but aren't there still
places we may end up blocking further down? Or are those ok?
>> From what I can tell, this indicates that pq_getbyte_if_available() is
>> not working - because it's supposed to never block, right?
>
> Right, it's not supposed to block.
>
>> This could be because the win32 socket emulation layer simply wasn't
>> designed to deal with non-blocking sockets. Specifically, it actually
>> *always* sets the socket to non-blocking mode, and then uses that to
>> properly emulate how sockets work under unix.
>
> I presume the win32 emulation layer can be taught about non-blocking
> sockets? Or maybe pq_getbyte_if_available() can be implemented using
> some other simpler method on Windows.
It could be taught that, but it would probably be a lot easier to put
platform specific code in pq_getbyte_if_available(). That's a bit
breaking an abstraction layer though, but that's maybe Ok in this
case...
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/