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 1ipQdu-0001gP-PP for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 05:46:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ipQdt-0005qD-FS for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 05:46:01 +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 1ipQdt-0005q6-3A for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 05:46:01 +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 1ipQdg-0002tV-6B for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 05:45:59 +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 0095jfE0022499; Thu, 9 Jan 2020 00:45:41 -0500 From: Tom Lane To: Noah Misch cc: Amit Khandekar , Amit Kapila , Alvaro Herrera from 2ndQuadrant , 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: <20200109053704.GA2502006@rfd.leadboat.com> References: <20200104185148.GA2270238@rfd.leadboat.com> <20200109053704.GA2502006@rfd.leadboat.com> Comments: In-reply-to Noah Misch message dated "Wed, 08 Jan 2020 21:37:04 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22497.1578548741.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 09 Jan 2020 00:45:41 -0500 Message-ID: <22498.1578548741@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Noah Misch writes: > Even so, a web search for "extend_brk" led to the answer. By default, 3= 2-bit > AIX binaries get only 256M of RAM for stack and sbrk. The new regressio= n test > used more than that, hence this crash. Hm, so (1) Why did we get a crash and not some more-decipherable out-of-resources error? Can we improve that experience? (2) Should we be dialing back the resource consumption of this test? Even on machines where it doesn't fail outright, I'd imagine that it's costing a lot of buildfarm cycles. Is it actually worth that? regards, tom lane