WIP patch - INSERT-able log statements - Mailing list pgsql-patches

From FAST PostgreSQL
Subject WIP patch - INSERT-able log statements
Date
Msg-id 13067.11061171582511.fast.fujitsu.com.au@MHS
Whole thread Raw
Responses Re: WIP patch - INSERT-able log statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WIP patch - INSERT-able log statements  (Greg Smith <gsmith@gregsmith.com>)
Re: WIP patch - INSERT-able log statements  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
Hi,

I've been working on the following TODO item and attached is an initial patch. (It is only partial and not yet
completelyfunctional) 

"Allow server log information to be output as INSERT statements
This would allow server log information to be easily loaded into a database for analysis. "

I want to confirm, if what I have done so far is what community is looking for and also want to clear some doubts.

What is done so far
---------------

Two postgresql.conf variables

#log_output_type = 'text'        #Valid values are 'SQL' or 'text'
#log_output_table_name = 'auditlogs'

These control how to output the log. Defaults to 'text' which is status quo. If it is set to 'SQL' log will be output
asINSERT commands. 

The second variable is of interest. We need to specify a table in the insert command. My preferred option is for the
userto give one and he can create it if and when he wants to. The alternative is we decide the table name and make
initdbto create one.   

The proposed log output structure
------------------
INSERT INTO user_defined_table values( timestamp_with_milliseconds,  timestamp, username,  databasename, sessionid,
host_and_port,host, proc_id, command_tag,  session_start, transaction_id,  error_severity,  SQL_State_Code,
error_message);

All these columns will follow the current rules of log output. ie, unless explicity requested by the user, these
columnswill have NULL. User can still give log_line_prefix in any order he wants, and logger will output it in
appropriatecolumns. The code has been modified to do  
this.

Issues/Questions are:
- How about 'Statement duration log'.  This will come to the logger as a single string and after the query execution.
Inthe existing log we can make sense of the duration log by matching it with the statement above it or by the statement
whichgets printed besides it (Again as  
a single string). But when this is loaded onto a table doesn't make much sense untless everything is in a single row.
(Mypreferred option is to add another column to the table structure defined above as 'duration'. But haven't figured
outhow to achieve this, because the  
statement is printed first and then the duration as another log.)

- If the SQL log output is to the syslog, then it becomes pretty awkward and possibly useless because our current
syslogwriter function breaks up the log into several lines to accomodate various platforms. Syslog also then adds other
informationbefore outputting it, which  
cannot be loaded onto a table. The preferred option is to educate the user through documentation that SQL type log
outputis best served when it is output to stderr and redirected to a file? Same goes with other aspects such as verbose
andvarious other statistics log.  

- There are also other minor issues such as, the actual query currently gets output in log as 'Statement: CREATE
........'.For sql type log we may not need the 'Statement:' part as it will be in a column ? Do we remove this in both
textand SQL outputs ? 

Rgds,
Arul Shaji

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 

Attachment

pgsql-patches by date:

Previous
From: Jeremy Drake
Date:
Subject: Re: patch adding new regexp functions
Next
From: Alvaro Herrera
Date:
Subject: remove dbname arg from bootstrap mode