(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
of newer
 * 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to