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 1j6K16-00039I-WA for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Feb 2020 20:07:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j6K15-00070F-LR for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Feb 2020 20:07:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j6K15-000708-CO for pgsql-hackers@lists.postgresql.org; Mon, 24 Feb 2020 20:07:47 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j6K12-0004wT-Cs for pgsql-hackers@lists.postgresql.org; Mon, 24 Feb 2020 20:07:47 +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 01OK7cEY017682; Mon, 24 Feb 2020 15:07:38 -0500 From: Tom Lane To: Andres Freund cc: Alvaro Herrera , Thomas Munro , =?utf-8?B?UsOpbWk=?= Zara , Michael Paquier , PostgreSQL Hackers Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API. In-reply-to: <20200224200119.x27tfdybwpzde3cy@alap3.anarazel.de> References: <16353.1582555469@sss.pgh.pa.us> <20200224191453.GA711@alvherre.pgsql> <20200224200119.x27tfdybwpzde3cy@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Mon, 24 Feb 2020 12:01:19 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17680.1582574857.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Feb 2020 15:07:37 -0500 Message-ID: <17681.1582574857@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote: >> I suppose we do use the C runtime. There's a reference to >> _setmaxstdio() being able to raise the limit from the default of 512 to >> up to 8192 open files. We don't currently invoke that. >> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setmax= stdio?view=3Dvs-2019 > If we ever go for that, we should also consider raising the limit on > unix systems up to the hard limit when hitting the fd ceiling. I.e. get > the current limit with getrlimit(RLIMIT_NOFILE) and raise rlim_cur > [closer] to rlim_max with setrlimit. I'm disinclined to think we should override the user's wishes in this way. Especially given PG's proven ability to run the kernel completely out of file descriptors ... regards, tom lane