I convinced that current patch has a problem, and will come up
with the new patch later.
====
> > 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.
>
> If so, what if replication is terminated and restarted repeatedly while
> a restartpoint is running? It sometimes obeys and sometimes ignores
> checkpoint_segments. Which seems strange behavior.
I see your point. And agree on that is something not should be.
> > Plus, adding SharedStartupStandbyMode into
> > XLogCtlData seems accompanied with some annoyances which would
> > not pay.
>
> Hmm... what are you worried about? I don't think that sharing the variable
> via XLogCtl is so difficult. Please see the code to share archiveCleanupCommand
> from the startup process to the checkpointer. It looks very simple.
The mechanism has nothing complex. I've been afraid of making so
many variables with similar meaning sitting side by side on
shared memory. But I convinced that additional shared variable is
preferable because it makes the logic and behavior clear and
sane.
I will come up with updated patch soon.
> > By the way, do you have some advise about GetStandbyFlushRecPtr()
> > and the order of the locations? I'm embarrassed with that...
>
> Sorry. I could not parse this.... Could you explain this again?
My point is,
- Is the assumption correct that "restorePtr <= replayPtr <= receivePtr"?
- If correct, what the code in GetStandbyFlushRecPtr() showing below means?
> if (XLByteLT(receivePtr, replayPtr))
- Or if wrong, what situation would take place to break the expression "restorePtr <= replayPtr <= receivePtr"?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
== My e-mail address has been changed since Apr. 1, 2012.