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 1vzWnC-0015Sk-0g for pgpool-hackers@arkaria.postgresql.org; Mon, 09 Mar 2026 09:20:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vzWnA-00FEZT-2I for pgpool-hackers@arkaria.postgresql.org; Mon, 09 Mar 2026 09:20:49 +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.96) (envelope-from ) id 1vzWnA-00FEZM-1l for pgpool-hackers@lists.postgresql.org; Mon, 09 Mar 2026 09:20:49 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vzWn8-00000001lzY-0XT1 for pgpool-hackers@lists.postgresql.org; Mon, 09 Mar 2026 09:20:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:To:Message-Id:Date:Sender: Reply-To:Cc:Content-ID:Content-Description; bh=kI4B4Bxj0bp4Q6JzyGZjf9es2QvD96fkqcEZpDWU9dU=; b=hegXtdYAXnu/dbBwfAc91LjK3Y cQJf73nvf4p6014jzkAblsyCdjRB8Ze8Qitb+JyOJeYK3LuKbgI+Lg0rkdSacs9QqAHawBx6p/q16 LrbbiMS1Cb6nflb/FgOo4i7YO4wR49jy6Ix+Pys1a9KxtEtHjZA4/ZTGbGJqr4poHUMYtFpRIxIgD 3/6GAingtHMIYq/UDgKMpwT42m9zX6Y4jjW1JK2uhA1Ma5/+rgVaWRyfoIxCPGgHgoJtnC1eGle0Q cDrHb2EX6/3d265SQp4an3Q018B301MW2ZEx4jNjvxl1dvCCcFi6whSvjevrvfsGcpRmXNwlAB/lb L1iSeO7A==; Received: from [2409:11:4120:300:426:3c3a:d97a:18e5] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vzWn5-00B8zZ-33 for pgpool-hackers@lists.postgresql.org; Mon, 09 Mar 2026 09:20:46 +0000 Date: Mon, 09 Mar 2026 18:20:31 +0900 (JST) Message-Id: <20260309.182031.585673783467995854.ishii@postgresql.org> To: pgpool-hackers@lists.postgresql.org Subject: Re: Close listening socokets before forking From: Tatsuo Ishii In-Reply-To: <20260302.100028.1346768433787074248.ishii@postgresql.org> References: <20260302.100028.1346768433787074248.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:426:3c3a:d97a:18e5 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Currently when pgpool main process forks sub processes (child process > - user session process, pcp_main process, health check process, > streaming replication check process and life check process), they > inherits pgpool and pcp listening sockets. However some of processes > do not need those sockets: > > - child process - pcp sockets are unnecessary > - pcp main process - pgpool sockets are unnecessary > - health check, streaming replication check and life check process - > pgpool and pcp sockets are unnecessary > > It could be potential problem when those process go down. Since they > may keep the listening sockets for a while, which prevents next pgpool > starting up from binding those ports. > > Attached patch closes those unnecessary sockets after forking. For > this purpose new function close_listening_sockets() is introduced. Pushed down to v4.4 (v4.3 was hard to port the patch). Best regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp