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

Re: WIP patch - INSERT-able log statements

From: "FAST PostgreSQL" <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>
To: Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: WIP patch - INSERT-able log statements
Date: 2007-02-22 04:25:19
Message-ID: 13067.11531172031915.fast.fujitsu.com.au@MHS (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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


In response to

Responses

pgsql-hackers by date

Next:From: Greg SmithDate: 2007-02-22 04:46:32
Subject: Re: WIP patch - INSERT-able log statements
Previous:From: Warren TurkalDate: 2007-02-22 04:23:16
Subject: SCMS question

pgsql-patches by date

Next:From: Greg SmithDate: 2007-02-22 04:46:32
Subject: Re: WIP patch - INSERT-able log statements
Previous:From: FAST PostgreSQLDate: 2007-02-22 01:43:32
Subject: Re: WIP patch - INSERT-able log statements

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