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  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctlstart without --wait
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling)