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.89) (envelope-from ) id 1ipZgj-0007SI-B5 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 15:25:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ipZgi-00079Y-3C for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 15:25:32 +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 1ipZgh-000776-Mn for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 15:25:31 +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 1ipZge-0007WV-Vx for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 15:25:30 +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 009FPM2a006486; Thu, 9 Jan 2020 10:25:22 -0500 From: Tom Lane To: Alvaro Herrera cc: Amit Kapila , Noah Misch , Amit Khandekar , Andres Freund , Juan =?iso-8859-1?Q?Jos=E9_Santamar=EDa?= Flecha , PostgreSQL Hackers , Robert Haas , Thomas Munro , Tomas Vondra Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files In-reply-to: <20200109144429.GA27927@alvherre.pgsql> References: <20200109144429.GA27927@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Thu, 09 Jan 2020 11:44:29 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6484.1578583522.1@sss.pgh.pa.us> Date: Thu, 09 Jan 2020 10:25:22 -0500 Message-ID: <6485.1578583522@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > Hmm, so why not revert the test only in the back branches, given that > it's not so onerous in master? I grow tired of repeating myself, but: it's purely accidental that this test passes in master for the existing set of buildfarm members. If I have to do so to prove my point, I will set up a buildfarm member that uses USE_NAMED_POSIX_SEMAPHORES, and then insist that the patch cope with that. But the real issue is that the test is abusing max_files_per_process to do something it was never intended for. What it was intended for, and works well at, is to constrain the total FD consumption of a collection of backends. It doesn't work well to constrain the maximum allocatedDescs consumption, because there's too much variability in our demand for other FDs. If we feel that we should have a test that is constraining that, then we need to invent some other mechanism to do it with. If we're not willing to invent an appropriate mechanism to support the test, then we should drop the test, because a half-baked test is worse than none. An appropriate mechanism, perhaps, would be some way to constrain max_safe_fds directly, without any platform- or environment-dependent effects in the way. It could be as simple as /* * Take off the FDs reserved for system() etc. */ max_safe_fds -= NUM_RESERVED_FDS; + /* + * Apply debugging limit, if defined. + */ +#ifdef MAX_SAFE_FDS_LIMIT + max_safe_fds = Min(max_safe_fds, MAX_SAFE_FDS_LIMIT); +#endif + /* * Make sure we still have enough to get by. */ and then somebody who was concerned about this could run a buildfarm member with "-DMAX_SAFE_FDS_LIMIT=10" or so. regards, tom lane