Hello, thank you for comment. > > In the backported version to 9.1.3, bgwriter.c is modified > > instead of checkpointer.c in 9.2. And GetWalRcvWriteRecPtr() is > > used as the equivalent of GetStandbyFlushRecPtr() in 9.2. > > In 9,2, GetXLogReplayRecPtr() should be used instead of > GetStandbyFlushRecPtr(). A restartpoint is scheduled to finish > before next restartpoint is triggered. A restartpoint is > triggered if too much WAL files have been replayed since last > restartpoint. So a restartpoint should be scheduled according > to the replay location not the receive location.
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; This seems imply receivePtr may be behind replayPtr. I don't understand what condition makes it but anyway the bottom line I think is that a restartpoint should be based on WALs surely synced. So I choosed GetStandbyFlushRecPtr() to read the location. If receivePtr/restorePtr always precede or are equal to replayPtr, I prefer GetXLogReplayRecPtr() as you suggest. (And some comment about the order among these pointers might should be supplied for the part) > I think that basically it's better not to change the comments > (i.e., not to add the line feed) if their contents are the same > as previous ones, to highlight what you actually changed in the > patch. Hmm. It is a priority matter between pointing up in or compactness of a patch and consistency in outcome of that. I think the latter takes precedence over the former. Altough, I could have found a description on better balance. But more than that, I've found fill-column for this comment be too short... > Typo: RedoRecptr should be RedoRecPtr? I think that's right. I've unconsciously brought that spelling from the orignal comment. regards, -- Kyotaro Horiguchi NTT Open Source Software Center == My e-mail address has been changed since Apr. 1, 2012. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers