Re: Problem during Windows service start

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

In response to

Responses

Browse pgsql-hackers by date

  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