Re: Avoiding adjacent checkpoint records

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Avoiding adjacent checkpoint records
Дата
Msg-id 13899.1339014289@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Avoiding adjacent checkpoint records  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Avoiding adjacent checkpoint records  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 6, 2012 at 3:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In commit 18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724, Simon modified the
>> rule for when to skip checkpoints on the grounds that not enough
>> activity has happened since the last one.

> IIRC, the inspiration for the change was that we were getting a
> never-ending series of checkpoints even when nothing was happening at
> all:
> http://archives.postgresql.org/pgsql-hackers/2011-10/msg00207.php

Right.

> I felt (and still feel) that this was misguided.

Looking at it again, I'm inclined to agree.  The behavior was entirely
correct up until somebody decided to emit a continuing stream of
XLOG_RUNNING_XACTS WAL records even when the system is idle.  Why did
we not fix it by fixing that?

> I don't think there's much sense in doing push-ups to avoid having the
> current and previous checkpoint records are on the same XLOG page.

Perhaps not.  I only got exercised about it after noting that the commit
hadn't updated the comment about it to match what the code is doing.
If we end up reverting that commit and doing something else to fix the
useless-checkpoint problem, I'm happy to let the subject rest, at least
until we get some evidence of a real problem in the area.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Avoiding adjacent checkpoint records