Skip site navigation (1) Skip section navigation (2)

Re: Checkpointer on hot standby runs without looking checkpoint_segments

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: simon(at)2ndQuadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, heikki(dot)linnakangas(at)enterprisedb(dot)com, masao(dot)fujii(at)gmail(dot)com
Subject: Re: Checkpointer on hot standby runs without looking checkpoint_segments
Date: 2012-07-02 09:08:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


Kyotaro Horiguchi
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: Marc CousinDate: 2012-07-02 09:32:50
Subject: small bug on 3-digit years in 9.2-dev
Previous:From: Andres FreundDate: 2012-07-02 09:03:58
Subject: Re: [PATCH 14/16] Add module to apply changes from an apply-cache using low-level functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group