Skip site navigation (1) Skip section navigation (2)

Re: On Logging

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: On Logging
Date: 2005-09-30 22:54:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Sep 26, 2005 at 10:57:54AM -0700, Ron Mayer wrote:
> David Fetter wrote:
> >...log file formats in 8.0....
> >
> >* CSV
> >* YAML
> >* XML
> >* Piped logs, as Apache can do
> >* DB handle.  I know this one will be controversial.
> >[...]
> >1.  Am I the only one who would wants an option for machine-readable logs?
> I'd very much like a format that can be easily loaded into
> a database (not necessarily the same one producing the logs :-) )
> in real time and/or be visible as a table through something
> like dbi-link.
> I suppose any of the first three formats you suggest could work
> with dbi-link; or another alternate format
>   * sql insert statements
> would work if piped logs were supported by sending it to psql.

Apache seems to have the best, most flexible logging of anything out
there, and should probably be used as a model. It's pretty easy to have
it actually log to a database.

Whatever method we decide on, I think it would be very useful if we
supported multiple logging streams. I certainly wouldn't want to give up
a human-readable log to get a CSV one.

Is a logging mechanism the best way to do profiling? Seems like it might
be better to have a more efficient, dedicated method. But I'm not
against adding capabilities like per-backend logging, etc.
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-09-30 22:57:50
Subject: Re: Open items list for 8.1
Previous:From: Jim C. NasbyDate: 2005-09-30 22:47:09
Subject: Re: Open items list for 8.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group