> > 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.
>
> Even when walreceiver is not running and WAL files are read from the archive,
> checkpoint_segments can trigger a restartpoint. In this case, ISTM a
> restartpoint
> should be scheduled according to checkpoint_segments, so I don't think that
> checking WalRcvInProgress() for that purpose is right thing. Instead, what about
> sharing StandbyMode flag among processes via shared memory like XLogCtl?
I tried that at first. But I suppose the requirement here is 'if
reading segments comes via replication stream, enable throttling
by checkpoint_segments.' and WalRcvInProgress() seems fit to
check that. Plus, adding SharedStartupStandbyMode into
XLogCtlData seems accompanied with some annoyances which would
not pay.
By the way, do you have some advise about GetStandbyFlushRecPtr()
and the order of the locations? I'm embarrassed with that...
> > 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?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
== My e-mail address has been changed since Apr. 1, 2012.
