Gavin Sherry wrote:
> 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
