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

RE Tom: If you check my query I have subtracted state_change timestamp that
is returned by pg_stat_activity, and according to my knowledge state_change
returns the last time the state got changed for the session, and if it's
saying 28 minutes then I suppose this means from 28 minutes the session did
not change state from idle. About you second "how" question, I set the
timeout in postgresql.conf file and didn't do it directly in the session. I
will double check if I made this mistake or not but I remember that I
changed the config and then restarted PostgreSQL service and then checked
if the timeouts got set by querying from them, only then I started my
queries. But I will try it again for making sure that what you said might
be the problem

On Wed, Aug 30, 2023 at 12:58 PM Emile Amewoto <emileam(at)yahoo(dot)com> wrote:

> Hi David,
> PostgreSQL does create and maintain connections on request because it is
> “expensive” to create new connections. Wouldn’t possible in your case to
> control the idle connections from the apps requesting connections? Things
> like reducing app thread pool? PostgreSQL ignore (rightfully) some of the
> configs even if it is set.
>
> Regards,
> Emile
>
> > On 29 Aug 2023, at 23:46, 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.
> >
> >> Not sure how you got 28 minutes from 45748…which is large enough that
> it is
> >> probable those sessions started before you changed the timeout and so
> are
> >> not affected by it.
> >
> > I believe idle_session_timeout is consulted when the session goes
> > idle, and we either set a timeout interrupt or not. The prevailing
> > value might change after that, but it won't affect existing sessions
> > until they next go idle. I do not regard that as a bug.
> >
> > 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.
> >
> > regards, tom lane
> >
> >
>
>