Re: log bind parameter values on error

There appears to be a problem with how this affects current logging
behavior.

I'm using

pgbench -M extended -S -T 10 bench

to test the extended protocol.

Unpatched, with log_statement=all, you get something like

LOG: execute <unnamed>: SELECT abalance FROM pgbench_accounts WHERE aid
= $1;
DETAIL: parameters: $1 = '30223'

With your patch, with log_statement=all and log_parameters=on, you get
the same, but with log_statement=all and log_parameters=off you get

LOG: execute <unnamed>: SELECT abalance FROM pgbench_accounts WHERE aid
= $1;
DETAIL: parameters: $1 = UNKNOWN TYPE

We should probably keep the existing parameter logging working as before.

This also raises the question of the new parameter name. Parameters are
already logged. So the name should perhaps be more like
log_parameters_on_error.

Some API notes on your patch: I think you can change
get_portal_bind_parameters() to take a ParamListInfo, since you're not
doing anything with the Portal other than grab the parameters. And that
would allow you to keep the signature of errdetail_params() unchanged.

I did some performance tests using the commands shown above and didn't
find any problems. Obviously the default pgbench stuff isn't very
parameter-intensive. Do you have tests with more and larger parameter
values?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services