|From:||Alexey Bashtanov <bashtanov(at)imap(dot)cc>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: log bind parameter values on error|
|Views:||Raw Message | Whole Thread | Download mbox|
> 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
Thanks for spotting this, I've fixed it, see the new patch attached.
> This also raises the question of the new parameter name. Parameters are
> already logged. So the name should perhaps be more like
> 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
I've done some tests, but they are not very reproducible:
the difference between runs is more than the difference between master
vs feature branch
and log_parameters_on_error on vs off.
I was using a small java app, it tested the speed using only a single
See its code and the results attached.
I'm sorry for the delay, feel free to move it to next commitfest if needed.
|Next Message||Alexander Korotkov||2019-01-28 00:22:27||Re: jsonpath|
|Previous Message||Stefan Keller||2019-01-27 23:22:05||Re: "SELECT ... FROM DUAL" is not quite as silly as it appears|