Magnus Hagander <mag...@hagander.net> writes: > 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.
Ugh. > 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. I think that on some platforms, it's possible for the call to select() from a shlib such as libpq to be captured by a select() provided by the executable it's loaded into. Dunno about the linking rules on Windows, but is there any chance of a workaround that way? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers