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 1tG00E-000Kix-T7 for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Nov 2024 18:09:34 +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 1tG00D-008ofy-KS for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Nov 2024 18:09:33 +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.94.2) (envelope-from ) id 1tG00D-008ofo-8v for pgsql-hackers@lists.postgresql.org; Tue, 26 Nov 2024 18:09:33 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tG00A-0041CQ-GW for pgsql-hackers@postgresql.org; Tue, 26 Nov 2024 18:09:31 +0000 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa51d32fa69so611061466b.2 for ; Tue, 26 Nov 2024 10:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732644568; x=1733249368; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DftUHONOjZBTIWW+05V24XhqvwufJx7tfYUtlWzYgSs=; b=nLkLS+GiBQ/mGlgJm82VLHWaQrwierjVWPqVAEXrUO6YxoMy/fCmmFvq4NeMo9OFOr RwLPcRiuuL2hFiQySH4Xb/NVUWbWuARP2ZdUmI+jRcM3cShNT9QmXPADTnprqu/L67tx 4n6JgIRBAPFSvP7fLfRw2cnKSVmplfTBdqxZ7VSGCTfp4cNHWxkgzUk6tS1wGcNMchIk 9RRiYUAcJD+qfBsBLj6RvYc/Sm7DORdEAMPHfFQSQQgrfrjAtAzpju6Bpg1F6Ahu4ugY NwbBkzS+aMctcpwx169tMwyucOH4xygsBJ2eiXl0Uh8dLEHGfkfliOFlrTvaIi+kuki7 FhTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732644568; x=1733249368; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DftUHONOjZBTIWW+05V24XhqvwufJx7tfYUtlWzYgSs=; b=qq84wVDUooOHgGgZlll1E7kfrXFhC9rCH/tr0etA8hfhjx8DVXJ/PnpkqgrFZULFMp Qf1wsiFidcXud0Xd1iIioFwvLvoKjjwetfZTEk3OX0fKZAEMTDdisZEJKFRe+ZB6zV4o 51+zJpdx+VX++ibjiCL38iVBN61HbOP72YKY7XzMRoRqG8XnEr4z8R/PP68YaptbhlLs tJXIKn1A8uCaoY7IlOSv/tcKjejL5pTDi/hq4GejwW7rGVh8RqDTKy8MQWXSVjT8KdTA 1YxyZIq3Qap/KWSX9Zc0arPCoZTSKisbAV9YaJZt9ZkKeYnIAFmhXiChlUshIlYMc0B3 4IsQ== X-Forwarded-Encrypted: i=1; AJvYcCWX5LtKpJzejyaga2S6fxbFBuwaMufQxsPTnuebC0DFHVNdq0EfVspPaL40BLOx6L26ZGL1lGO8PkO9+khE@postgresql.org X-Gm-Message-State: AOJu0YxOrxOjKcdBwsq7cmjaz+RVzFkniCEn+ArsMVqSOi6lgWZkIxuX JdzE6RQzR9BdGbs7mdSz3DRgc8GMQFkzx1ZPfs3dnDHOCg2H4HBDTVQfOIjQJq73KwBIDkz0fxu 9TOrqisbKTdITKlvNUAFfP2/EZUXNCg== X-Gm-Gg: ASbGncs5xH64e7nZ/UJe+fnxV4ZDU+6ijFz/EoI8SV1QJwMNR7QNOyoKU5NXcl5F3c5 Pdeu/030HBTrRiienVSgf1vZa4fvnNe4= X-Google-Smtp-Source: AGHT+IHkACG+7eHXLOaRVM5O5M75EZi+7SB1WndHPaxJjshTijMsQfVifp6pgcJsFvBSMXhogM5l0HXZTuxjY06w6IY= X-Received: by 2002:a17:906:3cb1:b0:aa5:2d9a:1528 with SMTP id a640c23a62f3a-aa52d9a1585mr1053886566b.60.1732644567944; Tue, 26 Nov 2024 10:09:27 -0800 (PST) MIME-Version: 1.0 References: <1682220.1732638956@sss.pgh.pa.us> In-Reply-To: <1682220.1732638956@sss.pgh.pa.us> From: Robert Haas Date: Tue, 26 Nov 2024 13:09:16 -0500 Message-ID: Subject: Re: Misleading "epoll_create1 failed: Too many open files" To: Tom Lane Cc: Andres Freund , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Nov 26, 2024 at 11:36=E2=80=AFAM Tom Lane wrote= : > I think the idea was that this mechanism is equivalent to an EMFILE > limit. But if you feel a need to make a distinction, this seems fine: I think we should never, ever confuse an error return from a system call with any other kind of problem that can happen. Not even write() returns 0 =3D> ENOSPC. AFAIK, the rationale for conflating failure cases like this is that either both failures are unlikely or, at least, the case where errno wasn't actually set is unlikely. But the problem is that when something weird happens, that's exactly when you need a clear and unambiguous error report. I've had multiple extremely painful support experiences that were made painful precisely because I couldn't determine exactly what really happened. Did a system call really return an unlikely error code? Or was it the not-a-real-error-code-but-we-faked-one case which is also not supposed to happen? I find this kind of thing maddening every time it happens, and it happens to me more often than you might think, because it often happens that other people are able to answer the normal questions and they send me the weird ones. Let's say twice a year I spend a couple of days sweating blood trying to determine the root cause of some bizarre malfunction because the person who wrote the code couldn't be bothered to take 2 minutes to make the errors distinguishable. --=20 Robert Haas EDB: http://www.enterprisedb.com