Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
Date
Msg-id CAM103DuQ5XymE=yhCNUTpLYaFKq3tJ92VoPrXV+mdHbrn9Yu1A@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
List pgsql-hackers
Hello, this message is attached with the patch which did not
tested. That is for show the way.

On Tue, Apr 17, 2012 at 9:38 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> But I think referring checkpoint_segment on such case should be
> inhibited, and I suppose it is possible using StandbyMode in
> IsCheckpointOnSchedule(), I suppose.
>
> I will correct the patch later.

Hmm. StandbyMode is a local variable which cannot be accessed in
checkpointer. But WalRcvInProgress() which shows if wal receiver
is running seems to be usable to ENABLE governing progress by
checkpoint_segments.

| IsCheckpointOnSchedule(double progress)
| {
....
|    /*
|     * Inhibit governing progress by segments in archive recovery.
|     */
|    recovery_in_progress = RecoveryInProgress();
|    if (!recovery_in_progress || WalRcvInProgress())
|    {
|            recptr = recovery_in_progress ? GetXLogReplayRecPtr(NULL) :
|                    GetInsertRecPtr();


How about this?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Gsoc2012 idea, tablesample
Next
From: Jay Levitt
Date:
Subject: Re: Bug tracker tool we need