Re: Skip checkpoint on promoting from streaming replication

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Skip checkpoint on promoting from streaming replication
Дата
Msg-id CA+U5nMJ-C6PdN6eqD6JFZTViGvCW1xV_v38=+CWR0vnQoKO3Mg@mail.gmail.com
обсуждение исходный текст
Ответ на Skip checkpoint on promoting from streaming replication  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Skip checkpoint on promoting from streaming replication  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On 8 June 2012 09:22, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:

> I have a problem with promoting from hot-standby that exclusive
> checkpointing retards completion of promotion.

Agreed, we have that problem.

> I depend on this and suppose we can omit it if latest checkpoint
> has been taken so as to be able to do crash recovery thereafter.

I don't see any reason to special case this. If a checkpoint has no
work to do, then it will go very quickly. Why seek to speed it up even
further?

> This condition could be secured by my another patch for
> checkpoint_segments on standby.

More frequent checkpoints are very unlikely to secure a condition that
no checkpoint at all is required at failover.

Making a change that has a negative effect for everybody, in the hope
of sometimes improving performance for something that is already fast
doesn't seem a good trade off to me.

Regrettably, the line of thought explained here does not seem useful to me.

As you know, I was working on avoiding shutdown checkpoints completely
myself. You are welcome to work on the approach Fujii and I discussed.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: New Postgres committer: Kevin Grittner
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Inconsistency in libpq connection parameters, and extension thereof