Michael,
* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Wed, Jan 18, 2017 at 10:35 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Wed, Jan 18, 2017 at 7:31 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >> Perhaps we need a way for pg_ctl to realize a cold-standby case and
> >> throw an error or warning if --wait is specified then, but that hardly
> >> seems like the common use-case. It also wouldn't make any sense to have
> >> anything in the init system which depended on PG being up in such a case
> >> because, well, PG isn't ever going to be 'up'.
> >
> > Yeah, it seems to me that we are likely looking for a wait mode saying
> > to exit pg_ctl once Postgres is happily rejecting connections, because
> > that means that it is up and that it is sorting out something first
> > before accepting them. This would basically filter the states in the
> > control file that we find as acceptable if the connection test
> > continues complaining about PQPING_REJECT.
>
> Another option would be as well to log the state of the control file
> to the user to let him know what currently happens, and document that
> increasing the wait timeout is recommended if the recovery time since
> the last redo point takes longer.
I was actually thinking about it the other way- start out by changing
them to both be 5m and then document next to checkpoint_timeout (and
max_wal_size, perhaps...) that if you go changing those parameters (eg:
bumping up checkpoint_timeout to 30 minutes and max_wal_size up enough
that you're still checkpointing based on time and not due to running out
of WAL space) then you might need to consider raising the timeout for
pg_ctl to wait around for the server to finish going through crash
recovery due to all of the outstanding changes since the last
checkpoint.
In particular, I like to think that will help people understand the
downsides of raising those values; I've run into a number of cases where
people seem to feel it's a win-win without any downside, but that isn't
really the case.
Thanks!
Stephen