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 1rBrCf-00ChDS-55 for pgsql-admin@arkaria.postgresql.org; Sat, 09 Dec 2023 06:52:45 +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 1rBrCd-00FjwR-PX for pgsql-admin@arkaria.postgresql.org; Sat, 09 Dec 2023 06:52:43 +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 1rBrCd-00FjwI-E0 for pgsql-admin@lists.postgresql.org; Sat, 09 Dec 2023 06:52:43 +0000 Received: from cloud.gatewaynet.com ([185.90.37.94]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rBrCa-00AwYQ-Ew for pgsql-admin@lists.postgresql.org; Sat, 09 Dec 2023 06:52:42 +0000 Message-ID: <0028c29e-26f3-48e7-9201-f94d2579b9ba@cloud.gatewaynet.com> Date: Sat, 9 Dec 2023 08:52:36 +0200 MIME-Version: 1.0 Subject: Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0 Content-Language: en-US To: Tom Lane Cc: pgsql-admin@lists.postgresql.org, nc@gatewaynet.com, Achilleas Mantzios References: <1436714.1702046865@sss.pgh.pa.us> <06bf30c8-371e-5575-e1cc-a6dc1140b8af@cloud.gatewaynet.com> <1454680.1702054572@sss.pgh.pa.us> <1552992.1702076062@sss.pgh.pa.us> From: Achilleas Mantzios In-Reply-To: <1552992.1702076062@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Στις 9/12/23 00:54, ο/η Tom Lane έγραψε: > Achilleas Mantzios writes: >> the trick is to have "application_name=" with no value.  This causes the >> server to not set application_name initially. > No, that sets it to an empty string, while application_name='' sets > it to two single quotes, according to the testing I did. In either > case, that value will be reported to the client as the active value > during connection start. Then the subsequent SET causes a new > report, but (since v14) only if the value being set is different. Thank you Tom, now I see we have a different behavior, I have uploaded a video that demonstrates my case : https://youtu.be/qcrVsFszV0Y I didn't have the time to fire up wireshark/tcpdump or debugger thought (I should). > >> Please check the scenario >> Client C1 connects to S1, sets application_name. BEGINS, COMMITS, the >> server gets freed to server the next client. >> Client C2 connects to the same S1, sets application_name, and gets no >> report back. So it stays with application_name empty. Then this breaks >> the application. >> How could pgbouncer prevent this from happening ? > pgbouncer would have to regurgitate the latest ParameterStatus > messages to the new client (during its faked-up initial connection > handshake) to ensure everything's synchronized correctly. > If for some reason it's not doing that, that would be a pretty > serious bug if you ask me, since clients might be relying on > hearing the truth about settings like client_encoding. Since > the whole point of pgbouncer is that the backend doesn't know > a new client has been slotted in, it's not clear to me how or > why the backend should solve this. You helped a great deal! It is time I open an issue on the pgbouncer project. > > regards, tom lane -- Achilleas Mantzios IT DEV - HEAD IT DEPT Dynacom Tankers Mgmt