Justin Pryzby <pryzby@xxxxxxxxxxxxx> 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
