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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
