Re: log bind parameter values on error
От | Alexey Bashtanov |
---|---|
Тема | Re: log bind parameter values on error |
Дата | |
Msg-id | ce9cd06a-ebb4-7978-ef2e-52a4d94d4fc4@imap.cc обсуждение исходный текст |
Ответ на | Re: log bind parameter values on error (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: log bind parameter values on error
Re: log bind parameter values on error Re: log bind parameter values on error |
Список | 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. Done > 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. Done > 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 connection. See its code and the results attached. I'm sorry for the delay, feel free to move it to next commitfest if needed. Best, Alex
Вложения
В списке pgsql-hackers по дате отправления: