Re: Problems with extended-Query logging code

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
>