Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h070M-0004rH-3A for pgsql-performance@arkaria.postgresql.org; Sat, 02 Mar 2019 15:56:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h070I-0008Ty-Os for pgsql-performance@arkaria.postgresql.org; Sat, 02 Mar 2019 15:56:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h070I-0008Tg-AN for pgsql-performance@lists.postgresql.org; Sat, 02 Mar 2019 15:56:46 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h070E-0003F2-Az for pgsql-performance@postgresql.org; Sat, 02 Mar 2019 15:56:44 +0000 Received: by mail-io1-xd44.google.com with SMTP id e186so726971ioa.0 for ; Sat, 02 Mar 2019 07:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=OX8v77fCHv7tC7p1Lbu8ynAyQ/2SjXuRCqidno/ph7o=; b=eNif4hP5Gibu4Dye+lsj4GY183cb5iUUTh0URYhHVjwmi/EtwPfqn7MOTRtLtw0xOs a3/A1p3wDc7a20/YJrRJPygwHnwqL/te82RzQb1QLVfNGlVGOxNW6vJtqNndnvhFiYu7 cnX4oWTN41Bdxg2/B+dAbd+oipJIcPyEkCGHZU5Ic790u5tB5gYCyrTiLSANYmR8upI3 Hu8gz6NtD1soVoigH0948rHY+bigv841g6K9gLdFBwjwnxMvwKMjI66tGRDZUIgoOfxh /0e6vOk7809mZr5PW5kdO4cfxsdIOOt7GnAnaDvgHq/uiwzEP/5pMS/DfH77fgXMj9uc A07Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=OX8v77fCHv7tC7p1Lbu8ynAyQ/2SjXuRCqidno/ph7o=; b=jbFiV0JIZ1ssHbRJK4rF9fIKWFDQ+U3YMHpL1M4g4Rvi/meYB7UoLBoP7mRg5KX7QX tMlk4lLxniSJc4CVkFgoX3+el8FYcN/AdSiJbwgmUDC2cdSnKzVqgdu7CXWd0+Q2jmFO O3W12X5GCB4BjvA0+8CMTewOEp+zBzr976Wk8WjzrdMHv7OApzyEdQm6VBvSa6+E/8cn EHauQ4DrDGOdVUru4/A/0iw3HN9x/kKQj8uPHEi1zmoZskLkEGWsQN84z1YKO3ST88vC /J3/nceH1pJeYgAoq4/nA+U1bae74OrRABBnQp5ZLM1xpADsbEpwOj8DDX3UjaJf8jWb Sm3Q== X-Gm-Message-State: APjAAAXMozdWZq6EUeBGAhyEPskX4vF5l7LCl7zRTlrGSB8X2hg31Gk0 ATXhvASPOlAi9nq95A/l8+FA6g== X-Google-Smtp-Source: APXvYqwYkkKPR1zWdl3HYXyRhqDw/8qCaD28I4r/pwGetZk0Q3/06DSKtC43wEFOlNouOR1imdkJzg== X-Received: by 2002:a6b:c545:: with SMTP id v66mr5962990iof.40.1551542201232; Sat, 02 Mar 2019 07:56:41 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id y18sm345948ioa.56.2019.03.02.07.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 07:56:40 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id AC47B800C83; Sat, 2 Mar 2019 09:56:38 -0600 (CST) Date: Sat, 2 Mar 2019 09:56:38 -0600 From: Justin Pryzby To: ROS Didier Cc: tgl@sss.pgh.pa.us, pgsql-performance@postgresql.org, legrand_legrand@hotmail.com Subject: Re: How to get the content of Bind variables Message-ID: <20190302155638.GA29584@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342fc1893b94ea0adecb400375ef365@PCYINTPEXMU001.NEOPROD.EDF.FR> <614c71eb156f49f696018916353fe454@PCYINTPEXMU001.NEOPROD.EDF.FR> <614c71eb156f49f696018916353fe454@PCYINTPEXMU001.NEOPROD.EDF.FR> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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. If it were using PQexecParams (protocol 2.0 "extended" query), it would show "execute : [...]", with any bind params in DETAIL. And if you were using PQexecPrepared, it'd show "execute FOO: [...]" where FOO is the name of the statement "prepared" by PQprepare (plus bind params). https://www.postgresql.org/docs/current/libpq-exec.html https://www.postgresql.org/docs/current/protocol.html What client application is this ? It looks like it's going to set deletion_date to the literal string "$1" .. except that it's not quoted, so the statement will just cause an error. Am I wrong ? Could you grep the entire logfile for pid 24803 and post the output on dropbox or pastebin or show 10 lines of context by email ? I've just used my messages and test cases on this patch as a reference to check what I wrote above is accurate. https://www.postgresql.org/message-id/flat/20190210015707.GQ31721%40telsasoft.com#037d17567f4c84a5f436960ef1ed8c49 On Fri, Mar 01, 2019 at 06:47:06PM +0000, ROS Didier wrote: > *) -> suggestion : It would be nice to have the content of bind variable of a query in a table of pg_catalog. (cf ORACLE) As I mentioned, you can set log_destination=csvlog,stderr and import them with COPY (and add indices and analysis and monitoring..). It look like DETAILs are being logged, so that's not the issue, but CSV also has the nice benefit of being easily imported to SQL where escaping and linebreaks and similar are not confusing the issue, which I think can be the case for text logs. Justin