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
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
> 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.
NTT Open Source Software Center
== My e-mail address has been changed since Apr. 1, 2012.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2012-06-12 03:03:10|
|Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)|
|Previous:||From: Robert Haas||Date: 2012-06-12 01:18:39|
|Subject: Re: Re: [COMMITTERS] pgsql: Add ERROR msg for GLOBAL/LOCAL
TEMP is not yet implemented|