Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0 - Mailing list pgsql-admin

From Tom Lane
Subject Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0
Date
Msg-id 1454680.1702054572@sss.pgh.pa.us
Whole thread Raw
In response to Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0  (Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com>)
Responses Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0
List pgsql-admin
Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com> writes:
> I would very much like this to have been a pgbouncer issue but it is 
> not. I was hoping I expressed the situation clearly, I am sorry if I 
> didn't. This is not about any multiple values per session, I send a 
> simple test below that reproduces the problem very easily (against *any* 
> pgbouncer 1.18+). The behavior of pgsql 16.1 is that it does not report 
> a SET application_name=... back to the client if the new value is the 
> same as the current one. This wasn't the behavior in pgsql 10.

No, but it's been true since v14 (cf commit 2432b1a04).  In any case,
the test case you're showing doesn't look like it'd exercise that
behavior, since the SET is installing a new value.

I did a bit of testing of the behavior of "application_name=" in the
connection string followed by an explicit SET, and AFAICS we do send
a ParameterStatus report from the SET, with no apparent change in
behavior from quite far back (I tried 9.5 for comparison).  So I
continue to maintain that this is a pgbouncer problem.  Maybe it
has not been updated for the no-duplicate-reports server behavior?
Although it's still hard to see why that would matter here.

            regards, tom lane



pgsql-admin by date:

Previous
From: Ron Johnson
Date:
Subject: Re: Related to Foreign Table Accessing
Next
From: Rajesh Kumar
Date:
Subject: Re: Postgres storage migration