David Fetter wrote:
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:
There are two other restrictions about the log files:
- There's no means of restricting logging on some patterns (e.g.
specific backends only, certain clients, certain events except for
log_duration)
- query is truncated due to UDP restrictions.
I'd call this not necessarily a logging issue, but a profiling issue. I
regularly use MSSQL's profiler to tap an application's query traffic, to
find out what's going on, and I'd like the same feature on pgsql.
This issue comes up on -hackers regularly, e.g. named logging to
tables/logging as inserts, and several others (I can cite them if
necessary).
What I'd like is an extended logging/profiling facility that can be
en/disabled with finer granularity (performance/data volume issues),
going to an intermediate file/whatever and regularly converted to table
data for easier evaluation (which would fix the format question in the
most pgsql like way).
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
