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 1qzIe8-00FMh2-3y for pgsql-jdbc@arkaria.postgresql.org; Sat, 04 Nov 2023 15:33:12 +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 1qzIe6-006Xtj-My for pgsql-jdbc@arkaria.postgresql.org; Sat, 04 Nov 2023 15:33:10 +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 1qzIe6-006Xta-Fh for pgsql-jdbc@lists.postgresql.org; Sat, 04 Nov 2023 15:33:10 +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 1qzIe4-004gRN-OR for pgsql-jdbc@lists.postgresql.org; Sat, 04 Nov 2023 15:33:09 +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 3A4FX6kb3477790; Sat, 4 Nov 2023 11:33:06 -0400 From: Tom Lane To: =?UTF-8?B?7J207IOB7JuQ?= cc: pgsql-jdbc@lists.postgresql.org Subject: Re: Connection Timeout Issue due to intermittent non-response of Postgre database In-reply-to: References: Comments: In-reply-to =?UTF-8?B?7J207IOB7JuQ?= message dated "Sat, 04 Nov 2023 20:41:13 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3477788.1699111986.1@sss.pgh.pa.us> Date: Sat, 04 Nov 2023 11:33:06 -0400 Message-ID: <3477789.1699111986@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =?UTF-8?B?7J207IOB7JuQ?= writes: > The Postgre database does not respond intermittently, causing a connection > timeout in the Spring Framework. There is no regularity in the occurrence > of connection timeouts and they do not repeat continuously. Not easy to > track. I'd try turning on statement logging, and maybe also statement duration logging, and then matching up the times of observed client-side outages with what's happening according to the postmaster log. Connection and disconnection logging might be useful too. A likely bet about the root cause is an unreasonably short connection timeout in some network infrastructure between your client and the database server. That would manifest as both sides reporting that the other side disconnected (not necessarily at the same time, but for the same connection). If so, it could likely be cured by adjusting the database's TCP keepalive settings. But you ought to gather data first. regards, tom lane