From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Achilleas Mantzios - cloud <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)com> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org, nc(at)gatewaynet(dot)com, Achilleas Mantzios <itdev(at)gatewaynet(dot)com> |
Subject: | Re: application_name backend (not) reporting back to the client : pgbouncer, PgSQL 16.1, pgbouncer 1.21.0 |
Date: | 2023-12-08 16:56:12 |
Message-ID: | 1454680.1702054572@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Achilleas Mantzios - cloud <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rajesh Kumar | 2023-12-08 19:05:13 | Re: Postgres storage migration |
Previous Message | Ron Johnson | 2023-12-08 16:16:28 | Re: Related to Foreign Table Accessing |