Hello, sorry for vague understanding. > > 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?
I want the standby to start to serve as soon as possible even by a few seconds on failover in a HA cluster. > > 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. I understand that checkpoint at the end of recovery is indispensable to ensure the availability of crash recovery afterward. Putting aside the convention about TLI increment and shutdown checkpoint, shutdown checkpoints there seems for me to be omittable if (and not 'only if', I suppose) crash recovery is available at the time. Shutdown checkpoint itself seems dispansable to me, but I'm shamingly not convinced so taking the TLI convention into consideration. > 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. Hmm.. I suppose the negative effect you've pointed is possible slowing down of hot-standby by the extra checkpoints being discussed in another thread, is it correct? Could you accept this kind of modification if it could be turned off by, say, GUC? > 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. Sorry, I'm afraid that I've failed to find that discussion. Could you let me have a pointer to that? Of cource I'd be very happy if the checkpoints are completely avoided on the approach. regards, -- Kyotaro Horiguchi NTT Open Source Software Center == My e-mail address has been changed since Apr. 1, 2012. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
