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. We could replace the blocking PQexec() calls with PQsendQuery(), and use the emulated version of select() to wait. > 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers