Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0

Achilleas Mantzios <a.mantzios@xxxxxxxxxxxxxxxxxxxx> · Sun, 10 Dec 2023 07:41:43 +0200

    Στις 10/12/23 00:08, ο/η Tom Lane
      έγραψε:

      Achilleas Mantzios <a.mantzios@xxxxxxxxxxxxxxxxxxxx> 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