Re: Checkpointer on hot standby runs without looking checkpoint_segments
От | Robert Haas |
---|---|
Тема | Re: Checkpointer on hot standby runs without looking checkpoint_segments |
Дата | |
Msg-id | CA+Tgmob5BqKvE0bX9fz3BxMeUphZjycgcAWb8qzoGkX+keUmmw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Checkpointer on hot standby runs without looking checkpoint_segments (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Checkpointer on hot standby runs without looking checkpoint_segments
|
Список | pgsql-hackers |
On Fri, Jun 8, 2012 at 9:58 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 8 June 2012 14:47, Robert Haas <robertmhaas@gmail.com> wrote: > >>> ISTM that we should avoid triggering a checkpoint on the master if >>> checkpoint_segments is less than wal_keep_segments. Such checkpoints >>> serve no purpose because we don't actually limit and recycle the WAL >>> files and all it does is slow people down. >> >> On the other hand, I emphatically disagree with this, for the same >> reasons as on the other thread. Getting data down to disk provides a >> greater measure of safety than having it in memory. Making >> checkpoint_segments not force a checkpoint is no better than making >> checkpoint_timeout not force a checkpoint. > > Not sure which bit you are disagreeing with. I have no suggested > change to checkpoint_timeout. You already made it not a hard timeout. We have another nearby thread discussing why I don't like that. > What I'm saying is that forcing a checkpoint to save space, when we > aren't going to save space, makes no sense. We are also forcing a checkpoint to limit recovery time and data loss potential, not just to save space. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: