Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j6EyO-0002k0-QW for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Feb 2020 14:44:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j6EyN-0005sG-3i for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Feb 2020 14:44:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j6EyM-0005s9-Nv for pgsql-hackers@lists.postgresql.org; Mon, 24 Feb 2020 14:44:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j6EyG-0000uz-4I for pgsql-hackers@lists.postgresql.org; Mon, 24 Feb 2020 14:44:37 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 01OEiTFe016354; Mon, 24 Feb 2020 09:44:29 -0500 From: Tom Lane To: Thomas Munro cc: =?UTF-8?Q?R=C3=A9mi_Zara?= , Michael Paquier , PostgreSQL Hackers Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API. In-reply-to: References: <20200220072435.GM2288@paquier.xyz> <08364CCB-07F5-423E-8CE0-ABF0195C4CA2@mac.com> <17106.1582224047@sss.pgh.pa.us> <19710.1582227844@sss.pgh.pa.us> <20263.1582228617@sss.pgh.pa.us> <26174.1582236314@sss.pgh.pa.us> <6610.1582242943@sss.pgh.pa.us> <18091.1582259407@sss.pgh.pa.us> <6230.1582494552@sss.pgh.pa.us> <27649.1582500247@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Mon, 24 Feb 2020 19:53:34 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16352.1582555469.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Feb 2020 09:44:29 -0500 Message-ID: <16353.1582555469@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > I suppose there may be users who have set ulimit -n high enough to > support an FDW workload that connects to very many hosts, who will now > need to set max_files_per_process higher to avoid the new error now > that we're doing this accounting. That doesn't seem to be a problem > in itself, but I wonder if the error message should make it clearer > that it's our limit they hit here. I struggled with the wording of that message, actually. The patch proposes + ereport(ERROR, + (errcode(ERRCODE_SQLCLIENT_UNABLE_TO_ESTABLISH_SQLCON= NECTION), + errmsg("could not connect to server \"%s\"", + server->servername), + errdetail("There are too many open files."))); I wanted to say "The server has too many open files." but in context it would seem to be talking about the remote server, so I'm not sure how to fix that. We could also consider a HINT, along the lines of "Raise the server's max_files_per_process and/or \"ulimit -n\" limits." This again has the ambiguity about which server, and it also seems dangerously platform-specific. regards, tom lane