Re: [HACKERS] Reducing pg_ctl's reaction time
От | Jeff Janes |
---|---|
Тема | Re: [HACKERS] Reducing pg_ctl's reaction time |
Дата | |
Msg-id | CAMkU=1xJW8e+CTotojOMBd-yzUvD0e_JZu2xHo=MnuZ4__m7Pg@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 Mon, Jun 26, 2017 at 12:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Jun 26, 2017 at 7:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The attached proposed patch adjusts pg_ctl to check every 100msec,
>> instead of every second, for the postmaster to be done starting or
>> stopping.
>> +#define WAITS_PER_SEC 10 /* should divide 1000000 evenly */
> As a matter of style, you could define 1000000 as well in a variable
> and refer to the variable for the division.
Good idea, done that way. (My initial thought was to use USECS_PER_SEC
from timestamp.h, but that's declared as int64 which would have
complicated matters, so I just made a new symbol.)
> This also pops up more easily failures with 001_stream_rep.pl without
> a patch applied from the other recent thread, so this patch had better
> not get in before anything from
> https://www.postgresql.org/message-id/8962.1498425057@ sss.pgh.pa.us.
Check. I pushed your fix for that first.
Thanks for the review!
regards, tom lane
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?
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: