Re: Load Distributed Checkpoints, take 3

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> Hmm. But if we're going to do that, we might as well have a checkpoint
>> for our troubles, no? The reason for the current design is the
>> assumption that a bgwriter_all scan is less burdensome than a
>> checkpoint, but that is no longer true given this rewrite.

> Per comments in CreateCheckPoint, another also skip the extra
> checkpoints to avoid writing two checkpoints to the same page, risking
> losing both on a crash:

That's not the reason for the current design --- that logic existed long
before bgwriter did.

Anyway, if there are no XLOG records since the last checkpoint, there's
probably nothing in shared buffers that needs flushing. There might be
some dirty hint-bits, but the only reason to push those out is to make
some free buffers available, and doing that is not checkpoint's job (nor
the all-buffers scan's job); that's what the LRU scan is for.

The only reason that the all-buffers scan was put in was to try to make
the next checkpoint cheaper. That reason falls to the ground with LDC.
What we have left is merely excess I/O.

regards, tom lane