Re: Logging checkpoints and other slowdown causes
От | Heikki Linnakangas |
---|---|
Тема | Re: Logging checkpoints and other slowdown causes |
Дата | |
Msg-id | 46445670.9020209@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Logging checkpoints and other slowdown causes ("Guillaume Smet" <guillaume.smet@gmail.com>) |
Список | 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 по дате отправления: