Re: log bind parameter values on error

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
Date: 2019-01-28 00:15:51
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi Peter,

> 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
> 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?

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.


Attachment Content-Type Size text/x-java 2.3 KB
params_benchmark.txt text/plain 2.6 KB
log_parameters_v005.patch text/x-patch 19.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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