Ok..... Summarizing the key changes required on my patch, based on the 
discussions so far are :

- The log_destination will include a new option 'sql'. This can be given with 
other combinations of stderr, syslog or eventlog. 
- The sql logs will be written in log_directory in a file log_filename.SQL 
- The log output will be in COPY format and will include the following 
information, irrespective of the log_line_prefix setting.
( timestamp_with_milliseconds,  timestamp, username,  databasename, 
sessionid,  host_and_port, host, proc_id, command_tag,  session_start, 
transaction_id,  error_severity,  SQL_State_Code, statement/error_message);

Anything else missing ? ? 

Arul Shaji

On Tue, 20 Feb 2007 19:03, Guillaume Smet wrote:
> On 2/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Of course, the other side of that coin is that syslog is known to drop
> > messages altogether under sufficient load.  (At least on some platforms;
> > dunno about yours.)
> Yes I know. That's one of the reason why I asked for the bahaviour of
> 7.4 log_duration back in 8.2. It's a good compromise which allows us
> not to lose lines and have a good level of information (at least, the
> best we can have). Async IO helps.
> Moreover we use syslog to send the log lines via UDP so we know that
> it's not perfect. But it works nice most of the time. We know that we
> can't log every query (we use a combination of log_duration and
> log_min_duration_statement - I patched 8.1 for that) because if we do
> so we lose a lot of lines and queries are not consistent but we can't
> do it locally with stderr anyway due to I/O. This method has been
> reliable for more than a year and our daily reports are consistent.

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 [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to