On Mon, Sep 5, 2011 at 7:52 PM, Tomas Vondra <t...@fuzzy.cz> wrote:
>> If your logging criteria for the write phase was "display a message any
>> time more than 30 seconds have passed since last seeing one", that would
>> give you only a few lines of output in a boring, normal
>> checkpoint--certainly less than the 9 in-progress samples you're
>> outputting now, at 10% intervals.  But in the pathological situations
>> where writes are super slow, your log data would become correspondingly
>> denser, which is exactly what you want in that situation.
> I still am not sure what should be a reasonable value or how to determine
> it. What happens when the checkpoint_timeout is increased, there's more
> shared_buffers etc.? What about using (checkpoint_timeout/10) for the
> time-based checkpoints and 30s for the other checkpoints?

I think the idea here is that we only need to log a message often
enough that the admin who is sitting there watching this won't get too
impatient waiting for the next one.  As that's not a function of
checkpoint_timeout, I don't see much value in conditioning this on
that.  +1 for the suggestion of 30s intervals - that seems infrequent
enough not to result in too much log spam, but sufficiently frequent
that anyone who is concerned about checkpoint progress won't have to
wait terribly long to find out how things are going.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to