On Tue, 1 Mar 2005, Joshua D. Drake wrote:
Hello,
I am looking at having one of our guys write up the code to allow logging as insert statements. I have a couple of questions.
What would we like the postgresql.conf option to be? I was thinking log_statements_as_inserts = (t/f)
However I thought that was getting a little silly. Also do we want to allow logging as inserts for all options? There is a lot of different types of logging we can do.
Seems to me that a better approach is a script which, given the log file format, is able to parse and allow the user to format the insert themselves.
The reason I say this is that users are almost always going to want a human readable log. As such, post processing the log outside of the database system seems to make sense.
The problem with the current format is that it's really hard to parse, esp. since log_line_prefix can be freely defined.
We just received a complaint about pgAdmin's log display mechanism, where the reading of the logfile over a connection will lead to noise in the logfile from the pgAdmin queries with log_statement=all. Reading the logfiles in a different way doesn't make things much better: the underlying problem is that for client side diagnosis in production systems it should be possible to tap only *some* backends with full log information (including duration, io statistics etc) while other traffic is ignored. I had to do this quite often, and using a logfile which logs all traffic won't make you happy for that purpose.
If all logging would go to a table which has appropriate columns to restrict the result set to investigate, this could help.
An important note: the log column should contain the *complete* query, not just a truncated one (as we have from stats_command_string) caused by some IPC limitation.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
