On 6-Sep-06, at 6:01 PM, Tom Lane wrote:
I happened to notice that the recently added code to log Bind-message
parameters was printing garbage into my log. On investigation it
turned
out to be trying to print an already-pfree'd string. That's fixable,
but having looked at the code closely, I see a bunch of other stuff
I'm
not happy about either:
* It's overly verbose: printing the same parameters twice seems
excessive.
* It's inefficient: it's spending effort on formatting and copying
parameter information around, whether or not there's any chance of
that information ever being wanted.
* It doesn't log the values of parameters sent in binary mode, which
is something that at least JDBC needs.
AFAIK, we don't need binary mode right away, currently we only send
bytea parameters in binary mode
If we could get the text parameters it would be a big win.
Another issue, which isn't the fault of the recent patches but has
been
there right along, is that execution of Parse or Bind could take
awhile
(due to planning of a complex query) but there's no log_duration or
log_min_duration_statement coverage for these message types.
Here are some thoughts about fixing it:
* For extended-Query mode I propose that we treat log_duration and
log_min_duration_statement as being effectively per-message not
per-statement. That is, we'd log a Parse or Bind operation if it
individually exceeded the duration threshold, and not otherwise.
* I'm inclined to think that Parse and Bind shouldn't be logged at
all,
or maybe only at DEBUG2 or higher, unless logged by duration logging.
If we've got support for logging the statement text and the parameter
values at Execute time, isn't logging the preliminary steps just
bloating the log?
* I think that the best way to log bind-parameter values is to run the
datatype output functions on the saved parameter values. This works
whether they were sent in text or binary mode, and avoids any extra
overhead at Bind time that might not be repaid.
Comments?
regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
