On Mon, Jun 26, 2017 at 12:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paqu...@gmail.com> writes: > > On Mon, Jun 26, 2017 at 7:13 AM, Tom Lane <t...@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.1498425...@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
