Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qb6Y5-00B8Q4-GA for pgsql-bugs@arkaria.postgresql.org; Tue, 29 Aug 2023 21:46:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qb6Y3-00BX3f-CS for pgsql-bugs@arkaria.postgresql.org; Tue, 29 Aug 2023 21:46:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qb6Y3-00BX3Q-3D for pgsql-bugs@lists.postgresql.org; Tue, 29 Aug 2023 21:46:54 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qb6Xz-001oWC-KJ for pgsql-bugs@lists.postgresql.org; Tue, 29 Aug 2023 21:46:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 37TLknIb049265; Tue, 29 Aug 2023 17:46:49 -0400 From: Tom Lane To: "David G. Johnston" cc: "maliansari.coder@gmail.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #18075: configuration variable idle_session_timeout not working as expected In-reply-to: References: <18075-d8a1bf11f070743e@postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Tue, 29 Aug 2023 14:12:00 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <49263.1693345609.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Aug 2023 17:46:49 -0400 Message-ID: <49264.1693345609@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Tuesday, August 29, 2023, PG Bug reporting form > wrote: >> I have set the idle_session_timeout variable as 60000 making it 60 seco= nds >> 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=E2=80=A6which is large enough= that it is > probable those sessions started before you changed the timeout and so ar= e > 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