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 1rYEAG-00Ewc8-OZ for pgsql-bugs@arkaria.postgresql.org; Thu, 08 Feb 2024 23:50:45 +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 1rYEAF-004RI7-5k for pgsql-bugs@arkaria.postgresql.org; Thu, 08 Feb 2024 23:50:43 +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 1rYEAE-004RHx-Tb for pgsql-bugs@lists.postgresql.org; Thu, 08 Feb 2024 23:50:42 +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 1rYEA7-006D4e-UG for pgsql-bugs@lists.postgresql.org; Thu, 08 Feb 2024 23:50:42 +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 418NoW2K1273951; Thu, 8 Feb 2024 18:50:32 -0500 From: Tom Lane To: Andres Freund cc: Etsuro Fujita , Alexander Lakhin , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17828: postgres_fdw leaks file descriptors on error and aborts aborted transaction in lack of fds In-reply-to: <20240208215920.myib264liwbkdndp@awork3.anarazel.de> References: <17828-122da8cba23236be@postgresql.org> <423731.1678381075@sss.pgh.pa.us> <1adf8fee-5a9a-69c2-057a-87bbddebab9d@gmail.com> <974582.1707411864@sss.pgh.pa.us> <20240208215920.myib264liwbkdndp@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Thu, 08 Feb 2024 13:59:20 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1273949.1707436232.1@sss.pgh.pa.us> Date: Thu, 08 Feb 2024 18:50:32 -0500 Message-ID: <1273950.1707436232@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > I think we ought to understand *why* we are getting the "Too many open > files". The AcquireExternalFD() in CreateWaitEventSet() should prevent > that. Actually, I think the AcquireExternalFD() in CreateWaitEventSet() is *causing* that and needs to be removed. What is happening in Alexander's new example is that we are doing AcquireExternalFD() for each postgres_fdw connection (cf. libpqsrv_connect in libpq-be-fe-helpers.h), and the example is tuned to bring that exactly up to the limit of what AcquireExternalFD() allows. Then the next WaitLatchOrSocket call fails, because it does WaitEventSet *set = CreateWaitEventSet(CurrentResourceOwner, 3); Then when pgfdw_abort_cleanup tries to clean up the connections' state, it needs to do WaitLatchOrSocket again, and that fails again, and we PANIC because we're already in abort state. Since WaitLatchOrSocket is going to free this WaitEventSet before it returns, it's not apparent to me why we need to count it as a long-lived FD: we could just as well assume that it can slide in under the NUM_RESERVED_FDS limit. Or perhaps use ReserveExternalFD instead of AcquireExternalFD. We'd need some API extension to tell latch.c to do that, but that doesn't seem hard. (Unless we could consider that all WaitEventSets should use ReserveExternalFD? Not sure I want to argue for that though.) I guess a third possibility is that WaitLatchOrSocket could just permanently hang onto the WaitEventSet once it's got one. > One annoying bit is that AcquireExternalFD() failing emits the same error as > if epoll_create1() itself failing, including the same errno. It's the former. I tend to agree now that maybe using the same error text wasn't too smart. regards, tom lane