Re: PATCH: regular logging of checkpoint progress

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: regular logging of checkpoint progress
Date: 2011-09-06 02:58:53
Message-ID: CA+TgmoZ_Peg9xmtQiOLxf4wYApsMY5tjo-2GmuwKika2Shs2hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 5, 2011 at 7:52 PM, Tomas Vondra <tv(at)fuzzy(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2011-09-06 04:22:18 Re: Couple document fixes
Previous Message Robert Haas 2011-09-06 02:55:33 Re: [v9.1] sepgsql - userspace access vector cache