Skip site navigation (1) Skip section navigation (2)

Re: PATCH: regular logging of checkpoint progress

From: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
To: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: regular logging of checkpoint progress
Date: 2011-08-25 23:49:15
Message-ID: eb41e89c2d6e687ebf9eb4c4c78057f2.squirrel@sq.gransy.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 26 Srpen 2011, 0:39, Tomas Vondra wrote:
> On 26 Srpen 2011, 0:18, Josh Berkus wrote:
>> Tomas,
>>
>>> I'd like to propose a small patch that allows better checkpoint
>>> progress
>>> monitoring. The patch is quite simple - it adds a new integer GUC
>>> "checkpoint_update_limit" and every time checkpoint writes this number
>>> of
>>> buffers, it does two things:
>>
>> I'd rather not have a new GUC if we can avoid it.  What about just
>> making this some reasonable value (like 1000 buffers) if log_checkpoints
>> = on?
>
> I was thinking about that too, but I think no value can fit all cases
> because the systems may have very different I/O subsystems.
>
> With one 7.2k drive I usually get about 25MB/s on average, with big arrays
> / good controllers / fast drives you can write much faster. So either the
> value will be too low (and the log will be infested with those messages)
> or too high (so it won't be updated very often).

Hmmm, maybe we could use time instead of number of buffers? Something like
"every 5 seconds, log the checkpoint progress" instead of "every time 1000
buffers is written ..."

That should work on systems regardless of I/O performance.

But although using time instead of number of buffers seems like a good
idea, I don't think it eliminates the need for a new GUC.

(a) Even with time limit, I find it useful to be able to set the limits
differently.

(b) In some cases it may be useful to enable just basic (current
behaviour) checkpoint logging using log_checkpoints, so using it for this
new patch may not be a good idea. Although this could be fixed by allowing
three values no/basic/detailed instead of just true/false.

Tomas


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-08-26 00:54:26
Subject: pg_upgrade problem (fwd)
Previous:From: Tomas VondraDate: 2011-08-25 22:39:14
Subject: Re: PATCH: regular logging of checkpoint progress

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group