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 ? ?
Rgds,
Arul Shaji
On Tue, 20 Feb 2007 19:03, Guillaume Smet wrote:
> On 2/20/07, Tom Lane <tgl@sss.pgh.pa.us> 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
ordinaryuser 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
thisemail 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
emailunsubscribe@fast.fujitsu.com.au
