(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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
