2010/1/17 Heikki Linnakangas <heikki.linnakan...@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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers