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: http://www.postgresql.org/mailpref/pgsql-hackers
