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 1rBe9Q-00Bhuw-K9 for pgsql-admin@arkaria.postgresql.org; Fri, 08 Dec 2023 16:56:32 +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 1rBe9O-009jj8-Md for pgsql-admin@arkaria.postgresql.org; Fri, 08 Dec 2023 16:56:30 +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 1rBe9O-009jiz-BB for pgsql-admin@lists.postgresql.org; Fri, 08 Dec 2023 16:56:30 +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 1rBe9L-00AqqL-Ly for pgsql-admin@lists.postgresql.org; Fri, 08 Dec 2023 16:56:29 +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 3B8GuCgs1454681; Fri, 8 Dec 2023 11:56:13 -0500 From: Tom Lane To: Achilleas Mantzios - cloud cc: pgsql-admin@lists.postgresql.org, nc@gatewaynet.com, Achilleas Mantzios Subject: Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0 In-reply-to: <06bf30c8-371e-5575-e1cc-a6dc1140b8af@cloud.gatewaynet.com> References: <1436714.1702046865@sss.pgh.pa.us> <06bf30c8-371e-5575-e1cc-a6dc1140b8af@cloud.gatewaynet.com> Comments: In-reply-to Achilleas Mantzios - cloud message dated "Fri, 08 Dec 2023 17:25:12 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1454679.1702054572.1@sss.pgh.pa.us> Date: Fri, 08 Dec 2023 11:56:12 -0500 Message-ID: <1454680.1702054572@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 would very much like this to have been a pgbouncer issue but it is > not. I was hoping I expressed the situation clearly, I am sorry if I > didn't. This is not about any multiple values per session, I send a > simple test below that reproduces the problem very easily (against *any* > pgbouncer 1.18+). The behavior of pgsql 16.1 is that it does not report > a SET application_name=... back to the client if the new value is the > same as the current one. This wasn't the behavior in pgsql 10. No, but it's been true since v14 (cf commit 2432b1a04). In any case, the test case you're showing doesn't look like it'd exercise that behavior, since the SET is installing a new value. I did a bit of testing of the behavior of "application_name=" in the connection string followed by an explicit SET, and AFAICS we do send a ParameterStatus report from the SET, with no apparent change in behavior from quite far back (I tried 9.5 for comparison). So I continue to maintain that this is a pgbouncer problem. Maybe it has not been updated for the no-duplicate-reports server behavior? Although it's still hard to see why that would matter here. regards, tom lane