Re: [HACKERS] Reducing pg_ctl's reaction time - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Reducing pg_ctl's reaction time
Date
Msg-id 20170626202356.qybnpn5li2ke4ioc@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Reducing pg_ctl's reaction time  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Reducing pg_ctl's reaction time  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2017-06-26 16:19:16 -0400, Tom Lane wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
> > The 10 fold increase in log spam during long PITR recoveries is a bit
> > unfortunate.
> 
> > 9153  2017-06-26 12:55:40.243 PDT FATAL:  the database system is starting up
> > 9154  2017-06-26 12:55:40.345 PDT FATAL:  the database system is starting up
> > 9156  2017-06-26 12:55:40.447 PDT FATAL:  the database system is starting up
> > 9157  2017-06-26 12:55:40.550 PDT FATAL:  the database system is starting up
> > ...
> 
> > I can live with it, but could we use an escalating wait time so it slows
> > back down to once a second after a while?
> 
> Sure, what do you think an appropriate behavior would be?

It'd not be unreasonble to check pg_control first, and only after that
indicates readyness check via the protocol. Doesn't quite seem like
something backpatchable tho.

- Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Reducing pg_ctl's reaction time
Next
From: David Fetter
Date:
Subject: Re: [HACKERS] \set AUTOROLLBACK ON