Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
От | wader2 |
---|---|
Тема | Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args |
Дата | |
Msg-id | 4A828697.6080706@jcom.home.ne.jp обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
|
Список | pgsql-hackers |
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@sss.pgh.pa.us> wrote: >> Magnus Hagander <magnus@hagander.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. > >
В списке pgsql-hackers по дате отправления: