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 usethe 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