Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0
От | Achilleas Mantzios |
---|---|
Тема | Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0 |
Дата | |
Msg-id | 8f67e40b-99bc-4a09-b0ad-c5c2eed10109@cloud.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0
|
Список | pgsql-admin |
The report, ok, I am talking about the startup packet. Please read below.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 client does not send the application_nameI 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
В списке pgsql-admin по дате отправления: