Re: [HACKERS] BUG #4961: pg_standby.exe crashes with no args

From: wader2 <wader2(at)jcom(dot)home(dot)ne(dot)jp>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] BUG #4961: pg_standby.exe crashes with no args
Date: 2009-08-12 09:08:39
Message-ID: 4A828697.6080706@jcom.home.ne.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs 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(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.
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Magnus Hagander 2009-08-12 09:14:13 Re: [HACKERS] BUG #4961: pg_standby.exe crashes with no args
Previous Message Sridhar 2009-08-12 07:34:36 BUG #4977: post installation failed

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-08-12 09:14:13 Re: [HACKERS] BUG #4961: pg_standby.exe crashes with no args
Previous Message Pierre Frédéric Caillaud 2009-08-12 08:48:19 Re: Table and Index compression