application_name backend (not) reporting back to the client : pgbouncer, PgSQL 14+, pgbouncer 1.18+ in transaction mode

[achix]

Hello
coming from the pgsql-admin list : https://www.postgresql.org/message-id/flat/e33e0231-77d7-4dd7-4b7c-97af1d0e091b%40cloud.gatewaynet.com

After this commit postgres/postgres@2432b1a postgresql refrains from reporting back a parameter to the client if the value set is unchanged. Now in transaction mode lets describe the following scenario :

Client C1 :
psql "postgresql://amantzio@localhost:6432/dynacom?application_name="
## ^^ it is vital that the above has no value after =
SET application_name='MyApp';
## Lets call the server that pgbouncer links C1 to as S1

Client C2 :
psql "postgresql://amantzio@localhost:6432/dynacom?application_name="
## ^^ it is vital that the above has no value after =
SET application_name='MyApp';
## Lets suppose/force C2 to connect to the same S1

We will notice that the application_name for C2 is empty.

What happens :
Client C1 connects to pgbouncer. Pgbouncer starts S1 and links C1 with S1. There is no application_name in the startup packet. Then C1 issues SET application_name='MyApp'; this gets executed in S1 and the backend identifies this as a change in value, correctly, so it reports back application_name to C1 which stores it in its state. All good.
Now C2 connects, and pgbouncer links the same S1 to serve C2. There is no application_name in the startup packet. Then C2 issues SET application_name='MyApp'; this gets executed in S1 and the backend identifies this as the same value as the one already set before, so it does not report back the application_name to C1. PROBLEM. This then may break the application.

Our workaround 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 pgbouncer .

I think this is a serious situation that must be either fixed or at least documented.

[achix]

Here is a short video of the reproduction of the problem :
https://www.youtube.com/watch?v=qcrVsFszV0Y