Re: log bind parameter values on error

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Alexey Bashtanov <bashtanov(at)imap(dot)cc>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log bind parameter values on error
Date: 2019-01-17 08:41:50
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

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

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

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

Peter Eisentraut
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-01-17 09:08:40 Re: Delay locking partitions during query execution
Previous Message Noah Misch 2019-01-17 08:27:07 Re: "could not reattach to shared memory" on buildfarm member dory