Re: Avoiding adjacent checkpoint records

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jun 6, 2012 at 4:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I felt (and still feel) that this was misguided.

>> Looking at it again, I'm inclined to agree. The behavior was entirely
>> correct up until somebody decided to emit a continuing stream of
>> XLOG_RUNNING_XACTS WAL records even when the system is idle. Why did
>> we not fix it by fixing that?

> That's exactly what I think we should have done.

Actually, it looks like there is an extremely simple way to handle this,
which is to move the call of LogStandbySnapshot (which generates the WAL
record in question) to before the checkpoint's REDO pointer is set, but
after we have decided that we need a checkpoint. That will result in
later iterations not thinking that some work had happened while the
checkpoint is in progress. It looks like we would need an extra
release/reacquire of WALInsertLock to avoid holding that lock while
doing LogStandbySnapshot, but that seems relatively negligible in
comparison to the total cost of a checkpoint.

There might be some still-better way to manage all this, but this one
seems safe enough to consider as a post-beta patch. So I recommend
we revert the change in the when-to-skip-checkpoint test in favor of
reordering these operations.

regards, tom lane