Re: [PATCHES] Load distributed checkpoint patch

Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> OK, if I understand correctly, instead of doing a buffer scan, write(),
> and fsync(), and recyle the WAL files at checkpoint time, you delay the
> scan/write part with the some delay.

Exactly. Actual behavior of checkpoint is not changed by the patch. Compared
with existing checkpoints, it just takes longer time in scan/write part.

> Do you use the same delay autovacuum uses?

What do you mean 'the same delay'? Autovacuum does VACUUM, not CHECKPOINT.
If you think cost-based-delay, I think we cannot use it here. It's hard to
estimate how much checkpoints delay by cost-based sleeping, but we should
finish asynchronous checkpoints by the start of next checkpoint. So I gave
priority to punctuality over load smoothing.

> As I remember, often the checkpoint is caused because
> we are using the last WAL file. Doesn't this delay the creation of new
> WAL files by renaming the old ones to higher numbers (we can't rename
> them until the checkpoint is complete)?

Checkpoints should be done by the next one, so we need WAL files for two
checkpoints. It is the same as now.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center