(catching up here)
On Sun, May 7, 2017 at 9:01 AM, Andres Freund <and...@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
* set. lastImportantAt is never cleared, only overwritten by the LSN
* records. Tracking the WAL activity directly in WALInsertLock has
* 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
It turns out that fixing this issue only on HEAD has been a good choice.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: