Skip site navigation (1) Skip section navigation (2)

Re: logging as inserts

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: logging as inserts
Date: 2005-03-02 17:35:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gavin Sherry wrote:
> On Tue, 1 Mar 2005, Joshua D. Drake wrote:
>>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.


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-03-02 17:54:20
Subject: Re: [HACKERS] UTF8 or Unicode
Previous:From: Dave CramerDate: 2005-03-02 16:04:21
Subject: Re: 8.0.X and the ARC patent

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group