From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Skip checkpoint on promoting from streaming replication |
Date: | 2012-06-08 09:28:12 |
Message-ID: | CA+U5nMJ-C6PdN6eqD6JFZTViGvCW1xV_v38=+CWR0vnQoKO3Mg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 June 2012 09:22, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-06-08 11:48:54 | Re: Inconsistency in libpq connection parameters, and extension thereof |
Previous Message | Boszormenyi Zoltan | 2012-06-08 09:10:15 | Re: New Postgres committer: Kevin Grittner |