(catching up here)
On Sun, May 7, 2017 at 9:01 AM, Andres Freund <andres@anarazel.de> wrote:
> Turns out this isn't the better fix, because the checkpoint code
> compares with the actual record LSN (rather than the end+1 that
> XLogInsert() returns). We'd start having to do more bookkeeping or more
> complicated computations (subtracting the checkpoint record's size).
> Therefore I've pushed the simple fix mentioned above instead.
Yeah, I have spent some time looking at many details for this stuff...
And using a start LSN location was way easier for the checkpoint skip
checks. e6c44ee looks good to me, except that I would complete this
comment block in xlog.c:* updated for all insertions, unless the XLOG_MARK_UNIMPORTANT flag
was* set. lastImportantAt is never cleared, only overwritten by the LSN
of newer* records. Tracking the WAL activity directly in WALInsertLock has
the* advantage of not needing any additional locks to update the value.*/
By just mentioning that the lastImportantAt is updated to the *start*
LSN position of an important record. This will help in avoiding future
confusions.
It turns out that fixing this issue only on HEAD has been a good choice.
--
Michael
