Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1o67-000Uek-Lj for pgsql-admin@arkaria.postgresql.org; Fri, 18 Oct 2024 14:36:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t1o65-005VHa-4s for pgsql-admin@arkaria.postgresql.org; Fri, 18 Oct 2024 14:36:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1o64-005VHS-Px for pgsql-admin@lists.postgresql.org; Fri, 18 Oct 2024 14:36:57 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1o62-001j13-An for pgsql-admin@lists.postgresql.org; Fri, 18 Oct 2024 14:36:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 49IEaYUB871997; Fri, 18 Oct 2024 10:36:34 -0400 From: Tom Lane To: Achilleas Mantzios - cloud cc: pgsql-admin@lists.postgresql.org, Achilleas Mantzios Subject: Re: Migrating from 10 -> 16, PreparedStatements disabled in JDBC and pgbouncer, I am getting : bind /C_5 In-reply-to: References: Comments: In-reply-to Achilleas Mantzios - cloud message dated "Fri, 18 Oct 2024 11:11:28 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <871995.1729262194.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Oct 2024 10:36:34 -0400 Message-ID: <871996.1729262194@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Achilleas Mantzios - cloud writes: > I have noticed in the pgsql 16.4 logs some lines with this pattern : > 10.9.0.110(45201) [4079203] 67122b3b.3e3e63 2024-10-18 12:32:44.260 EEST= = > SMA =C2=A0amantzio@dynacom line:35 LOG: =C2=A0duration: 0.166 ms =C2=A0p= arse : = > SELECT work_status FROM company_stuff WHERE ldap_cn =3D $ > 1 > 10.9.0.110(45201) [4079203] 67122b3b.3e3e63 2024-10-18 12:32:44.261 EEST= = > SMA =C2=A0amantzio@dynacom line:36 LOG: =C2=A0duration: 0.553 ms =C2=A0b= ind = > /C_5: SELECT work_status FROM company_stuff WHERE ldap_cn > =3D $1 > 10.9.0.110(45201) [4079203] 67122b3b.3e3e63 2024-10-18 12:32:44.261 EEST= = > SMA =C2=A0amantzio@dynacom line:38 LOG: =C2=A0duration: 0.036 ms =C2=A0e= xecute = > /C_5: SELECT work_status FROM company_stuff WHERE ldap_ > cn =3D $1 > So the parse is done on an unnamed prepared statement, however the bind = > and the execute show this : /C_5 after. We haven't got any log = > entries with this /C_* pattern on the "parse" phase, only on "bind" and = > "execute". I am curious what those represent. Here C_5 would be a portal name, identifying the bound-and-ready- to-execute query. See https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-E= XT-QUERY regards, tom lane