Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait |
Дата | |
Msg-id | CAB7nPqR08Cpu5JraVtWAqQPfPoxbS2kdzCu-DTxSaV5bEkONOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
|
Список | pgsql-hackers |
On Thu, Jan 19, 2017 at 5:01 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 1/18/17 8:25 AM, Stephen Frost wrote: >> 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. > > It is important for users to be aware of this, but I don't think the > relationship between checkpoint_timeout and recovery time is linear, so > it's unclear what the exact advice should be. This is a right assumption for steady workloads with few DDLs, but for example once a couple of CREATE DATABASE records are in such a law is broken. -- Michael
В списке pgsql-hackers по дате отправления: