Justin Pryzby <pryzby@telsasoft.com> 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
waitingfor 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
updatedtuple (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_valeursset 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