Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait |
Дата | |
Msg-id | 20170118132544.GX18360@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: