On 2016-02-03 09:57:00 -0500, Robert Haas wrote: > On Mon, Feb 1, 2016 at 7:43 PM, Andres Freund <and...@anarazel.de> wrote: > > I wonder if this essentially point at checkpoint_timeout being wrongly > > defined: Currently it means we'll try to finish a checkpoint > > (1-checkpoint_completion_target) * timeout before the next one - but > > perhaps it should instead be that we start checkpoint_timeout * _target > > before the next timeout? Afaics that'd work more graceful in the face of > > restarts and forced checkpoints. > > There's a certain appeal to that, but at the same time it seems pretty > wonky. Right now, you can say that a checkpoint is triggered when the > amount of WAL reaches X or the amount of time reaches Y, but with the > alternative definition it's a bit harder to explain what's going on > there.
Hm, but can you, really? We *start* a checkpoint every checkpoint_timeout, but we only finish it after checkpoint_completion_target * timeout, or cct * segments. I find it pretty hard to explain that we have a gap of checkpoint_timeout, where nothing happens, after an immediate/manual checkpoint. Defining it as: We try to *finish* a checkpoint every checkpoint_timeout or checkpoint_segments/(max_wal_size/~3) actually seems simpler to me. Then we just need to add that we start a checkpoint checkpoint_completion_target before either of the above are reached. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
