From: Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-admin@lists.postgresql.org, itdev <itdev@itdevel.internal.net>
Subject: Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0
Date: Sun, 10 Dec 2023 07:41:43 +0200
Message-ID: <8f67e40b-99bc-4a09-b0ad-c5c2eed10109@cloud.gatewaynet.com> (raw)
In-Reply-To: <1750352.1702159733@sss.pgh.pa.us>
References: <e33e0231-77d7-4dd7-4b7c-97af1d0e091b@cloud.gatewaynet.com>
<1436714.1702046865@sss.pgh.pa.us>
<06bf30c8-371e-5575-e1cc-a6dc1140b8af@cloud.gatewaynet.com>
<1454680.1702054572@sss.pgh.pa.us>
<ff2ee637-f3b6-424d-8ebf-d7cb089487de@cloud.gatewaynet.com>
<1552992.1702076062@sss.pgh.pa.us>
<0028c29e-26f3-48e7-9201-f94d2579b9ba@cloud.gatewaynet.com>
<addc9291-d3a3-4545-9805-8d1f00978614@cloud.gatewaynet.com>
<1750352.1702159733@sss.pgh.pa.us>
Στις 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: a.mantzios@cloud.gatewaynet.com, tgl@sss.pgh.pa.us, itdev@itdevel.internal.net
Subject: Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0
In-Reply-To: <8f67e40b-99bc-4a09-b0ad-c5c2eed10109@cloud.gatewaynet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox