Re: Checkpointer on hot standby runs without looking checkpoint_segments

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.