Re: Change GetLastImportantRecPtr's definition? (wasSkip checkpoints, archiving on idle systems.)
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-05-07T12:38:05Z
Lists: pgsql-hackers
(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
Commits
-
Fix off-by-one possibly leading to skipped XLOG_RUNNING_XACTS records.
- e6c44eef55cd 10.0 landed
-
Skip checkpoints, archiving on idle systems.
- 6ef2eba3f57f 10.0 cited