Ok, I agree to drop this patch from this CF.
> > - What I want to get is similarity of the behaviors between
> > master and (hot-)standby concerning checkpoint
> > progression. Specifically, checkpoints for streaming
> > replication running at the speed governed with
> > checkpoint_segments. The work of this patch is avoiding to get
> > unexpectedly large number of WAL segments stay on standby
> > side. (Plus, increasing the chance to skip recovery-end
> > checkpoint by my another patch.)
>
> I think we need to be clearer about this:
>
> I reject this patch and am moving to rejected on the CF manager.
>
> The "increase chance to skip recovery end checkpoint" is completely
> gone as a reason to do this (see other thread).
I don't know why you hate to decrease checkpoint interval so much
despite I proposed to do so only during WAL streaming (and
additionaly allowing it to be optional), we have another and
enough reason to want *to be able* to do so. Averaging disk usage
is not a trivial issue for some users or - I suppose (or hope?) -
not a few users. This is a subject not only of resource limit but
also of operation management.
> Plus the premise that we want more restartpoints is wrong, with
> reasons explained by Heikki, in detail, months ago.
Yes, It may make catching up in standby mode slower but it seems
to be a choice between the resource and performance.
But since I agree with that this is not a critical issue and with
the opinion that the chekcpoint planning somehow should be
smarter to make better balance between disk usage and
performance, I accept the judgement to drop this.
Thank you.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
== My e-mail address has been changed since Apr. 1, 2012.
