Greg Smith wrote:
On Fri, 11 May 2007, Heikki Linnakangas wrote:
Or we could add a GUC variable similar to log_connections or log_statement to control if the messages are printed or not, and use LOG.


If the levels for the individual messages are adjusted usefully the ability to control whether they show up or not falls out of the existing log level adjustments; I haven't ever felt a strong need for GUC when using this code. If, as you say, there's already a move in this direction, then fine--another GUC would be better.

The need for GUC becomes apparent when you start adding logging to other modules as well, like we did for autovacuum a while back. If there wasn't a log_autovacuum parameter, you'd have to choose between logging checkpoints and autovacuum actions, or neither.

We don't need to print the times elapsed in each phase on a separate line, that's just derived information from the other lines, unless we use different log-levels for detail lines

Let me turn this around for a second and ask you this: what do you think people are going to do with this information? I can tell you what I do. I parse the logs and look for that single line with the summary information. I then take the three pieces of information it provides (MB written, time to write, time to fsync) and save them into a table. From there I generate stats, scatter plots, all sorts of useful stuff.

If you know when the checkpoint ended, and you know how long each of the pieces took, you can reconstruct the other times easily. The way you describe this it is true--that the summary is redundant given the detail--but if you put yourself in the shoes of a log file parser the other way around is easier to work with. Piecing together log entries is a pain, splitting them is easy.

If I had to only keep one line out of this, it would be the one with the summary. It would be nice to have it logged at INFO.

Yeah, if we have the summary line we don't need the other lines and vice versa. I have sympathy for parsing log files, I've done that a lot in the past and I can see what you mean. Having the individual lines is nice when you're monitoring a running system; you don't get the summary line until the checkpoint is finished. I suppose we can have both the individual lines and the summary, the extra lines shouldn't hurt anyone, and you won't get them unless you turn on the new log_checkpoints parameter anyway.

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq

Reply via email to