On Logging

From: David Fetter <david(at)fetter(dot)org>
To: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: On Logging
Date: 2005-09-26 16:58:34
Message-ID: 20050926165834.GB13535@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Folks,

I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant effort to parse. For
example, pqa, a very clever piece of code, is mostly devoted to
parsing said files and works only with significant tweaking and
restrictions on log file formats in 8.0.

Simple logging is a default that should probably not change, but I'm
thinking that for people who want to find something out from the logs,
we could see about a kind of plugin architecture which would enable
things like:

* CSV
* YAML
* XML
* Piped logs, as Apache can do
* DB handle. I know this one will be controversial.

I'm thinking that a GUC variable (or should there be a class of them?)
called log_format would be part of the user interface to this and
would be able to switch from the cheap default code path to one that's
more expensive, just as log_statement does.

So, a few questions:

1. Am I the only one who would wants an option for machine-readable logs?
2. Am I way off with the idea for an architecture for same?
3. What big things am I missing here?

Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-09-26 17:00:21 Re: roundoff problem in time datatype
Previous Message Bruce Momjian 2005-09-26 16:58:04 Re: Patching dblink.c to avoid warning about open transaction