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