Greg Smith escribió:
> On 7/18/13 11:04 AM, Robert Haas wrote:
> >On a system where fsync is sometimes very very slow, that
> >might result in the checkpoint overrunning its time budget - but SO
> >WHAT?
> Checkpoints provide a boundary on recovery time.  That is their only
> purpose.  You can always do better by postponing them, but you've
> now changed the agreement with the user about how long recovery
> might take.
> And if you don't respect the checkpoint boundary, what you can't do
> is then claim better execution performance than something that did.
> It's always possible to improvement throughput by postponing I/O.
> SO WHAT? If that's OK, you don't need complicated logic to do that.
> Increase checkpoint_timeout.  The system with checkpoint_timeout at
> 6 minutes will always outperform one where it's 5.

I think the idea is to have a system in which most of the time the
recovery time will be that for checkpoint_timeout=5, but in those
(hopefully rare) cases where checkpoints take a bit longer, the recovery
time will be that for checkpoint_timeout=6.

In any case, if the system crashes past minute 5 after the previous
checkpoint (the worst possible timing), the current checkpoint will have
already started, so recovery will take slightly less time because some
flush work had already been done.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to