2010/1/18 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
Indeed.
>> 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?
AFAIK, no. We can somehow control the link order when we link with the
import library, but that would require us to do it at link time,
meaning libpq would be linked to postgres.exe --> FAIL.
Another option is to load the select() function on runtime, by having
libpq examine the list of loaded modules for postgres.exe.. But that
seems a lot uglier than providing some kind of callback for it.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
