Justin Pryzby <[email protected]> writes:
> On Fri, Mar 01, 2019 at 06:47:06PM +0000, ROS Didier wrote:
>> log_line_prefix = '%t [%p]: [%l-1] [%x] user=%u,db=%d,client=%h'
> On Sat, Mar 02, 2019 at 01:14:44PM +0000, ROS Didier wrote:
>> 2019-03-01 14:53:37 CET [24803]: [129-1] [3686]
>> user=pgbd_preint_sg2,db=pgbd_preint_sg2 LOG: process 24803 still waiting
>> for ShareLock on transaction 3711 after 1000.476 ms
>> 2019-03-01 14:53:37 CET [24803]: [130-1] [3686]
>> user=pgbd_preint_sg2,db=pgbd_preint_sg2 DETAIL: Process holding the lock:
>> 24786. Wait queue: 24803.
>> 2019-03-01 14:53:37 CET [24803]: [131-1] [3686]
>> user=pgbd_preint_sg2,db=pgbd_preint_sg2 CONTEXT: while rechecking updated
>> tuple (3,33) in relation "t_shared_liste_valeurs"
>> 2019-03-01 14:53:37 CET [24803]: [132-1] [3686]
>> user=pgbd_preint_sg2,db=pgbd_preint_sg2 STATEMENT: update
>> t_shared_liste_valeurs set deletion_date=$1, deletion_login=$2,
>> modification_date=$3, modification_login=$4, administrable=$5, libelle=$6,
>> niveau=$7 where code=$8
> I just realized that your log is showing "STATEMENT: [...]" which I think
> means that's using libpq PQexec (simple query protocol), which means it
> doesn't
> use or support bind parameters at all.
No, what's shown above is a case of the current statement being printed
as detail for some log message (a log_lock_waits message in this case).
This has nothing to do with whether statement logging is on overall.
I now realize that what the OP is probably wishing for is that bind
parameter values would be included as a detail line in messages other
than log_all_statements or statement-duration messages. Sorry, that
feature doesn't exist, and there'd be pretty serious technical
impediments to making it happen.
regards, tom lane
