From: | Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Ramanarayana <raam(dot)soft(at)gmail(dot)com>, "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Subject: | Re: Problem during Windows service start |
Date: | 2019-09-05 23:09:45 |
Message-ID: | 20190905230945.GA31656@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Jul-24, Kyotaro Horiguchi wrote:
> > Please find the proposed patch for review. I will attach it to
> > commitfest as well
>
> Pacemaker suffers the same thing. We suggest our customers that "start
> server alone to perform recovery then start pacemaker if it is
> expected to take a long time for recovery so that reaches time out".
>
> I don't think it is good think to let status SERVICE_RUNNING although
> it actually is not (yet). I think the right direction here is that, if
> pg_ctl returns by timeout, pgwin32_ServiceMain kills the starting
> server then report something like "timedout and server was stopped,
> please make sure the server not to take a long time to perform
> recovery.".
I'm not sure that's a great reaction; it makes total recovery time
even longer. How would the user ensure that recovery takes a shorter
time? We'd be forcing them to start the service over and over, until
recovery completes.
Can't we have pg_ctl just continue to wait indefinitely? So we'd set
SERVICE_START_PENDING when wait_for_postmaster is out of patience, then
loop again -- until recovery completes. Exiting pg_ctl on timeout seems
reasonable for interactive use, but maybe for service use it's not
reasonable.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-09-05 23:20:14 | Re: BUG #15383: Join Filter cost estimation problem in 10.5 |
Previous Message | Alvaro Herrera from 2ndQuadrant | 2019-09-05 22:56:22 | Re: [bug fix] Produce a crash dump before main() on Windows |