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
- standby_checkpoint_segments_9.2dev_fix_20120417.patch (text/x-patch) patch
- standby_checkpoint_segments_9.1.3_fix_20120417.patch (text/x-patch) patch
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.