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.96) (envelope-from ) id 1vnzX4-00EUAC-23 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Feb 2026 13:36:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vnzX2-00H43g-22 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Feb 2026 13:36:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnzX2-00H43Y-0m for pgsql-hackers@lists.postgresql.org; Thu, 05 Feb 2026 13:36:28 +0000 Received: from mail-dy1-x132b.google.com ([2607:f8b0:4864:20::132b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vnzWz-00000000gbc-30ws for pgsql-hackers@lists.postgresql.org; Thu, 05 Feb 2026 13:36:27 +0000 Received: by mail-dy1-x132b.google.com with SMTP id 5a478bee46e88-2b834e17c3fso842910eec.0 for ; Thu, 05 Feb 2026 05:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ardentperf-com.20230601.gappssmtp.com; s=20230601; t=1770298584; x=1770903384; darn=lists.postgresql.org; h=mime-version:references:in-reply-to:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=bCw5unjdPhOL9Eop5+iDfuq4eHMakN+y80YIDoAs04k=; b=2V09CwrTeVHtgXZ87rLio45a5UlgW9PcJRlSmn+G3d8RORJ26vqEBKlNDGiCTgFEvf c1S7f1fpNW7NTpqNxqrv9sASIe/4acOnt2RjCtJNVv+pw4pReWkzb+lpDmV/VxqlouHe UEmD3MnHp+EVoYo2m5TU6z1ZlRrkG45wg01nsMp83UnrMchQwCZ9oF0c+xxwOQYowvFH Wivd6w9rnXJk9Ks8YmTLS33tZhVGvQG48Ek/+fvfgbQJIhKx1wcHw1rwM19ZI9Wsil9U +aJ2PzEdiAttRw7wWKynOSS2uljLGVyR2/A+EfIgQgBOFip8WifHVa9JEINIFqlmdk02 Vzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770298584; x=1770903384; h=mime-version:references:in-reply-to:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bCw5unjdPhOL9Eop5+iDfuq4eHMakN+y80YIDoAs04k=; b=hCKJznlexlA4UqTsX8FSZ/5+ooG6rY/ONpsFaQIT+/ehmlxetABv21p7p8TgEWt1Jc MNe5TMZe5rNBdgWuc1EEr1aPa/QUJjMl+GeYyu1IuMc+9EmwoUeZej39aDdQQXGjLvmB FtUFxj1rT4mubv7FIy+vA2FxcGdPzwTLQVSdnmUPXIbiUBS75Mb7gV42sLS3iKvhUJ2r nkOjVFJlKiC5TDXwOdRup7QsTHKMGg1/nuwqRD25NJ229NfL3LqE9u8A/msflNHrPB25 /KHtyu1fLUSdf/+zO4K9CfB20tRGfr8Ms2X5xhh+fAqR7DIO6NIgM6+geShI9frS/tW0 Cydw== X-Gm-Message-State: AOJu0YyDs/4keAkOO+8yuls/vtk2VITU7QfE+1QGKwouw6KiSWKrj4US zTASGT9Cf1B9RJxP9Af+TBPC6oi1SrNI4rW0kK/Y6MWn3wTwFEnVTq+7Gx0MSJRVIV3P6eUJTgO z/Sk= X-Gm-Gg: AZuq6aKSiELIzblgu8Oszaq/62kVNyX8qKZTsWOCUzgX2ujKaa3lIrhW2dITLwCVN9b JNChSZNoVx1NUjcht+lGp71xUBxFv1Y7I1mdX0IntgohVQaA15hyfAVAmI2gEInsOcakn1qs5HN IJdzm2aeKbdl4K6bvYMwh4ivP+XIQ8LCKBPUthKu6Z5pNtNT7jufiJ0WmIHYacc/Yr/RI115GHJ Xglfo2ErYzRAm3V5Ggbf//7tBKeYJ+SOL9m2STrHdW/ZbtjyjtCCYGV9Jz8m9ozZ+Mxm/madU5e Q+nCX+rACHIeiUQsyDf4wV8g0I8EYAOePiVSjFxV4Kj+GwKMcXLp7O3pNjT7LMNV1oyLHAaju8X Ki95Ui92sKK96uIxRLGuVuUjiYTUk/p1NdX8exrEbXfoJrfVN5hyQKXIbPFmF03FAsEjhocD7Ll k1x/kmYVsHtTbVNU3GhbuQgxf2kgxBp0mzITP3WuE3IRISB9t49TqXd8sv9MVfHdPzXER2NUScB /ApBA== X-Received: by 2002:a05:7301:1688:b0:2b7:1e8f:c83a with SMTP id 5a478bee46e88-2b83299f33cmr3257691eec.32.1770298584229; Thu, 05 Feb 2026 05:36:24 -0800 (PST) Received: from ardentperf.com (97-113-67-23.tukw.qwest.net. [97.113.67.23]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b832fd7ae9sm3159170eec.31.2026.02.05.05.36.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 05:36:23 -0800 (PST) Date: Thu, 5 Feb 2026 05:36:21 -0800 From: Jeremy Schneider To: "pgsql-hackers@lists.postgresql.org" Cc: Marat Buharov Subject: Re: client_connection_check_interval default value Message-ID: <20260205053621.6c531b0e@ardentperf.com> In-Reply-To: <20260204213032.15bab46b@ardentperf.com> References: <20260204213032.15bab46b@ardentperf.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/qz2OYyXRpSnvpF48FALDBTl" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --MP_/qz2OYyXRpSnvpF48FALDBTl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 4 Feb 2026 21:30:32 -0800 Jeremy Schneider wrote: > What would people here think about changing the default value of > client_connection_check_interval to 2000 ms? Right now this is > disabled by default. Forgot the doc update in the attached patch. Updated -Jeremy --MP_/qz2OYyXRpSnvpF48FALDBTl Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-Change-default-client_connection_check_interval-to-2.patch From b23d89338daaec9c381783fe6a9df9d148aeace7 Mon Sep 17 00:00:00 2001 From: Jeremy Schneider Date: Wed, 4 Feb 2026 21:08:32 -0800 Subject: [PATCH] Change default client_connection_check_interval to 2000ms The default value of client_connection_check_interval is changed from 0 (disabled) to 2000ms (2 seconds). This enables periodic checking for client disconnection during long-running queries by default, which can help detect and clean up queries from disconnected clients more promptly. A value of 0 continues to disable connection checking for users who prefer the previous behavior. --- doc/src/sgml/config.sgml | 9 +++++---- src/backend/utils/misc/guc_parameters.dat | 2 +- src/backend/utils/misc/postgresql.conf.sample | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5560b95ee60..5bc7f029e80 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1059,10 +1059,11 @@ include_dir 'conf.d' If the value is specified without units, it is taken as milliseconds. - The default value is 0, which disables connection - checks. Without connection checks, the server will detect the loss of - the connection only at the next interaction with the socket, when it - waits for, receives or sends data. + The default value is 2000 (2 seconds). A value of + 0 disables connection checks. Without connection + checks, the server will detect the loss of the connection only at the + next interaction with the socket, when it waits for, receives or sends + data. For the kernel itself to detect lost TCP connections reliably and within diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat index f0260e6e412..91c0d740ce5 100644 --- a/src/backend/utils/misc/guc_parameters.dat +++ b/src/backend/utils/misc/guc_parameters.dat @@ -403,7 +403,7 @@ long_desc => '0 disables connection checks.', flags => 'GUC_UNIT_MS', variable => 'client_connection_check_interval', - boot_val => '0', + boot_val => '2000', min => '0', max => 'INT_MAX', check_hook => 'check_client_connection_check_interval', diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index c4f92fcdac8..8dd89d6da4e 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -87,7 +87,7 @@ #tcp_user_timeout = 0 # TCP_USER_TIMEOUT, in milliseconds; # 0 selects the system default -#client_connection_check_interval = 0 # time between checks for client +#client_connection_check_interval = 2000 # time between checks for client # disconnection while running queries; # 0 for never -- 2.43.0 --MP_/qz2OYyXRpSnvpF48FALDBTl--