I can't compile nor read source, but can tell you that
pg_standby.exe in 8.3.7 works fine.
Magnus Hagander wrote:
> On Mon, Aug 10, 2009 at 20:44, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> If I just move those two lines into the #ifndef WIN32 block just
>>> around it, it compiles and doesn't crash on running-with-no-arguments.
>>> I haven't tried to actually use it though - can someone confirm if
>>> this will actually make pg_standby not work properly?
>> It would mean there's no way to trigger failover via signal.
>>
>> I think what we need is for pg_ctl to be able to send these signals...
>
> Those signals don't *exist* on Windows. The whole idea of
> cross-process signals don't *exist* on Windows.
>
> We emulate it in the main backend, by creating a background thread
> that sets a global variable. That is then polled in the
> CHECK_FOR_INTERRUPTS macro. pg_ctl is perfectly capable of sending
> these signals, but pg_standby can't receive them.
>
> We could implement the same type of check in pg_standby, but it
> requires something like CHECK_FOR_INTERRUPTS. And these interrupts
> won't, by default, cause any kind of interruption of the process. In
> the backend, we interrupt socket calls because we have the socket
> wrapper layer, and nothing else. I don't know how doable this would be
> in pg_standby - does it always block on a single thing where we could
> stick some win32 synchronization code? If it's a single, or limited,
> places we could implement something similar to the backend. But if we
> need to interrupt at arbitrary locations, that's just not possible.
>
>