Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>

From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: masao.fujii@gmail.com
Cc: pgsql-hackers@postgresql.org
Date: 2012-04-17T06:50:46Z
Lists: pgsql-hackers

Attachments

This is new version of the patch.
I replaced GetStandbyFlushRecPtr with GetXLogReplayRecPtr to
check progress of checkpoint following Fujii's sugestion.

The first one is for 9.2dev, and the second is 9.1.3 backported version.

===
By the way, I took a close look around there,

> I agree with it basically. But I've get confused to look into
> GetStandbyFlushRecPtr().
> 
> |   if (XLByteLT(receivePtr, replayPtr))
> |     return XLByteLT(replayPtr, restorePtr) ? restorePtr : replayPtr;
> |   else
> |     return XLByteLT(receivePtr, restorePtr) ? restorePtr : receivePtr;

 - receivePtr seems always updated just after syncing received xlog.
 - replayPtr is updated just BEFORE xlog_redo operation, and
 - restorePtr is updated AFTER xlog_redo().
 - And, replayPtr seems not exceeds receivePtr.

These seems quite reasonable. These conditions make following
conditional expression.

     restorePtr <= replayPtr <= receivePtr

But XLByteLT(recievePtr, replayPtr) this should not return true
under the condition above.. Something wrong in my assumption?


Anyway, I understand here that you say the location returned by
GetXLogReplayRecPtr() is always flushed.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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