Re: WIP patch - INSERT-able log statements

On Wed, 21 Feb 2007 14:59, Greg Smith wrote:
> On Tue, 20 Feb 2007, Tom Lane wrote:
> > A smaller problem is that this forces people to incur a gettimeofday
> > call for every message logged
>
> I'm stumped trying to think of an application that would require importing
> the logs into a database to analyze them, but not need the timestamp.
> I'd expect it to be the primary key on the data.
>
> > Is it worth providing a knob to determine the set of columns emitted?
>
> Myself and Guillaume felt that having the format be standardized had
> significant value from a downstream application perspective; it would be

Come to think of it, this may not be ideal after all. As we are triggering
the sql output in log_destination, if the user gives 'syslog,sql' as options
he is going to get two different looking logs (in terms of contents)
depending upon his settings.

But if we take the settings from log_line_prefix then the log contents are
the same, plus it gives the user flexibility to control what he wants. If an
user wants everything he only has to fill the log_line_prefix completely.

Also, for a meaningful sql log output we may need to tell the user not to
turn on verbose or print_plan or statistics etc... With a uniform log output
it will be clear in that sense.. What he sets in .conf is what he gets, both
in syslog and sql log. This may not be an optimization. Only an option which
is there if any optimization is necessary.

I am happy to implement it either way though. My requirement is same as
yours. I want some sort of sql logging, pronto.

Rgds,
Arul Shaji

> nice to know that everyone can work together to write one simple tool
> chain to process these things and it would work everywhere. The current
> level of log output customization is part of what makes log analysis tools
> so much of a pain.
>
> How about this as a simple way to proceed: have the patch include
> everything, as Arul already planned. When it's done, do some benchmarking
> with it turned on or off. If it really seems like a drag, then consider a
> GUC addition to trim it down. Why optimize prematurely? It's not like
> this will be on by default. My guess is that the person sophisticated to
> analyze their logs probably has an installation that can support the
> overhead.
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.

If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(at)fast(dot)fujitsu(dot)com(dot)au