Re: [HACKERS] Reducing pg_ctl's reaction time
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Reducing pg_ctl's reaction time |
Дата | |
Msg-id | 20170626202356.qybnpn5li2ke4ioc@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Reducing pg_ctl's reaction time (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Reducing pg_ctl's reaction time
|
Список | 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 по дате отправления: