Re: Logging checkpoints and other slowdown causes - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: Logging checkpoints and other slowdown causes
Date
Msg-id 46445670.9020209@enterprisedb.com
Whole thread Raw
In response to Re: Logging checkpoints and other slowdown causes  ("Guillaume Smet" <guillaume.smet@gmail.com>)
List pgsql-patches
Guillaume Smet wrote:
> On 5/11/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
>> I agree that debug levels are not suitable for this.
>
> Squid (the (reverse) proxy) has a nice feature for debugging purposes
> (admin and developers). It's possible to have different logging level
> for different sections of the code. For example, if you want to debug
> a particular part, you can have ALL,1 33,2 in your config file which
> allows you to have a more verbose debug on the section 33 of the code
> (33 is ACL).
> It's really useful because you can even debug a particular code path
> or a misconfiguration in production without generating a huge amount
> of logs.

Yes, that'd be really nice, though using numeric codes is a bit archaic.
In Java-world, a logging framework called log4j has become the de facto
standard to implement logging. It's basically the same idea, you have
different log levels, and you can have enable different levels of
logging for different modules. I'm sure there's similar libraries for C,
that's something to think about in future releases.

8.3 will add some new log_* GUC variables, log_autovacuum and
log_temp_files, so it seems we're headed to that direction already. I'm
now thinking that's the approach we should take for checkpoints as well:
add a new GUC variable, log_checkpoints, and print the messages at
LOG-level if that's enabled.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: "Guillaume Smet"
Date:
Subject: Re: Logging checkpoints and other slowdown causes
Next
From: Greg Smith
Date:
Subject: Re: Logging checkpoints and other slowdown causes