Re: BUG #18075: configuration variable idle_session_timeout not working as expected

I managed to make it work as expected by using psycopg library to create
connection pool directly and disabling idle_session_timeout on PostgreSQL
as psycopg docs suggested that. The problem maybe pgbouncer or maybe some
other problem in PostgreSQL. Maybe pgbouncer disables idle_session_timeout
of PostgreSQL, but it's not written anywhere.

On Wed, Aug 30, 2023 at 10:27 PM Muhammad Ali Ansari <
maliansari(dot)coder(at)gmail(dot)com> wrote:

> I have no user specific settings. Here check the output.
> [image: image.png]
>
> On Wed, Aug 30, 2023 at 9:32 PM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Tue, Aug 29, 2023 at 2:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>>> > On Tuesday, August 29, 2023, PG Bug reporting form <
>>> noreply(at)postgresql(dot)org>
>>> > wrote:
>>> >> I have set the idle_session_timeout variable as 60000 making it 60
>>> seconds
>>> >> As we can see, it shows that the time is way more than 1 minute now
>>> it is
>>> >> 28 minutes and they are still idle and still open in postgres and not
>>> >> disconnected as expected.
>>>
>>> Also, the OP didn't say *how* he set idle_session_timeout. That
>>> pg_settings extract only proves that 60000 is the prevailing value in
>>> the session where that was done. It's possible that the value was
>>> only set locally, or in some other way that didn't affect those other
>>> sessions at all.
>>>
>>>
>> Yeah, the fact all of those are for "apiuser" suggests to me that user
>> has their own setting for this which takes precedence over the server
>> default.
>>
>> The output of \drds would be more informative than just looking at some
>> unknown session's value.
>>
>> David J.
>>
>>