Magnus Hagander <magnus@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