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?