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 1rCCZe-00EkAG-B9 for pgsql-admin@arkaria.postgresql.org; Sun, 10 Dec 2023 05:41:54 +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 1rCCZZ-005FOT-Vl for pgsql-admin@arkaria.postgresql.org; Sun, 10 Dec 2023 05:41:49 +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 1rCCZZ-005FOL-JL for pgsql-admin@lists.postgresql.org; Sun, 10 Dec 2023 05:41:49 +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 1rCCZX-00B9zQ-1W for pgsql-admin@lists.postgresql.org; Sun, 10 Dec 2023 05:41:48 +0000 Content-Type: multipart/alternative; boundary="------------Q0SFxQJ93CHUR4XU5Q0nDX1b" Message-ID: <8f67e40b-99bc-4a09-b0ad-c5c2eed10109@cloud.gatewaynet.com> Date: Sun, 10 Dec 2023 07:41:43 +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, itdev 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> <0028c29e-26f3-48e7-9201-f94d2579b9ba@cloud.gatewaynet.com> <1750352.1702159733@sss.pgh.pa.us> From: Achilleas Mantzios In-Reply-To: <1750352.1702159733@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------Q0SFxQJ93CHUR4XU5Q0nDX1b Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Στις 10/12/23 00:08, ο/η Tom Lane έγραψε: > Achilleas Mantzios writes: >> Hi again, I am puzzled with your observations, this is what I get with >> psql straight against PostgreSQL no pgbouncer involved : >> command : >> psql "postgresql://amantzio@localhost:5432/dynacom?application_name=" >> ... >> public.S....is_superuser.on.S....application_name..S...&default_transaction_read_only.off.S....scram_iterations.4096.S....DateStyle.ISO, > ^^^^^^^^^^^^^^^^^^^^^^^ > > I see the report of application_name with an empty-string value right > there. The report, ok, I am talking about the startup packet. Please read below. > >> the client does not send the application_name > I do not know what you mean by that, but maybe your client code has > some special-case behavior for an empty string? The above  was plain vanilla psql, nothing special. Let me show the two startup packets (psql -> pgsql) in each case : case 1: psql "postgresql://amantzio@localhost:5432/dynacom?application_name=" 23:29:00.415726 IP localhost.31933 > localhost.postgresql: Flags [P.], seq 1:62, ack 1, win 1277, options [nop,nop,TS val 1343970026 ecr 3656173586], length 61 E..q..@.@...........|..8...k2.M......e..... *P.Z........=....user.amantzio.database.dynacom.client_encoding.UTF8..* case 2: psql "postgresql://amantzio@localhost:5432/dynacom?application_name=''" 23:31:45.583486 IP localhost.13693 > localhost.postgresql: Flags [P.], seq 1:82, ack 1, win 1277, options [nop,nop,TS val 300427204 ecr 2261783934], length 81 E.....@.@...........5}.8.`Pc...1.....y..... *..'....~...Q....user.amantzio.database.dynacom.application_name.''.client_encoding.UTF8..* So, in the first case (application_name=) , there is not explicit setting of application_name by the client in the startup packet, whereas in the second case (application_name='') there is. On this observation we based our temporary solution for the core problem described in this thread : Our trick to workaround this , is to define a dummy string e.g. '' in the startup packet, followed by an explicit SET application_name='OurApplicationName' so that the backend always receives two consecutive settings, and always understands the 2nd as a changed value, so it always reports the correct application_name back to the pgbouncer . > > regards, tom lane -- Achilleas Mantzios IT DEV - HEAD IT DEPT Dynacom Tankers Mgmt --------------Q0SFxQJ93CHUR4XU5Q0nDX1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Στις 10/12/23 00:08, ο/η Tom Lane έγραψε:
Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> writes:

Hi again, I am puzzled with your observations, this is what I get with 
psql straight against PostgreSQL no pgbouncer involved :


      

        
command :
psql "postgresql://amantzio@localhost:5432/dynacom?application_name="


      

      

      

        
...
public.S....is_superuser.on.S....application_name..S...&default_transaction_read_only.off.S....scram_iterations.4096.S....DateStyle.ISO, 


      

      
                              ^^^^^^^^^^^^^^^^^^^^^^^

I see the report of application_name with an empty-string value right
there.

    

    The report, ok, I am talking about the startup packet. Please read
    below.

    

      



      

        
the client does not send the application_name


      

      
I do not know what you mean by that, but maybe your client code has
some special-case behavior for an empty string?

    

    
The above  was plain vanilla psql, nothing special. Let me show
      the two startup packets (psql -> pgsql) in each case :

    
case 1:  psql
          "postgresql://amantzio@localhost:5432/dynacom?application_name="

    
23:29:00.415726 IP
        localhost.31933 > localhost.postgresql: Flags [P.], seq 1:62,
        ack 1, win 1277, options [nop,nop,TS val 1343970026 ecr
        3656173586], length 61 

        E..q..@.@...........|..8...k2.M......e.....
        

        P.Z........=....user.amantzio.database.dynacom.client_encoding.UTF8..

    


    

    
case 2:  psql
          "postgresql://amantzio@localhost:5432/dynacom?application_name=''" 

    
23:31:45.583486 IP
        localhost.13693 > localhost.postgresql: Flags [P.], seq 1:82,
        ack 1, win 1277, options [nop,nop,TS val 300427204 ecr
        2261783934], length 81 

        E.....@.@...........5}.8.`Pc...1.....y.....
        

        ..'....~...Q....user.amantzio.database.dynacom.application_name.''.client_encoding.UTF8..

    


    

    
So, in the first case (application_name=) , there is not explicit
      setting of application_name by the client in the startup packet,
      whereas in the second case (application_name='') there is. 

    
On this observation we based our temporary solution for the core
      problem described in this thread : Our trick to workaround this ,
      is to define a dummy string e.g. '' in the startup packet,
      followed by an explicit SET application_name='OurApplicationName'
      so that the backend always receives two consecutive settings, and
      always understands the 2nd as a changed value, so it always
      reports the correct application_name back to the pgbouncer .

    

    

    

      

			regards, tom lane


    

    
-- 
Achilleas Mantzios
 IT DEV - HEAD
 IT DEPT
 Dynacom Tankers Mgmt

  


--------------Q0SFxQJ93CHUR4XU5Q0nDX1b--