ITAGAKI Takahiro wrote:
> Bruce Momjian <bruce@momjian.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?
Sorry, I meant bgwriter delay, not autovauum.
> 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.
OK.
> > 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.
Ah, OK, so we already reserve a full set of WAL files while we are
waiting for the checkpoint to complete.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
