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 1h48aK-00054Z-QE for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Mar 2019 18:26:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h48aJ-0001PY-Dq for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Mar 2019 18:26:35 +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 1h48aJ-0001PR-2k for pgsql-hackers@lists.postgresql.org; Wed, 13 Mar 2019 18:26:35 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h48aG-0007od-K4 for pgsql-hackers@lists.postgresql.org; Wed, 13 Mar 2019 18:26:33 +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 x2DIQSGS010789; Wed, 13 Mar 2019 14:26:28 -0400 From: Tom Lane To: Robert Haas cc: Alvaro Herrera , PostgreSQL Hackers Subject: Re: hyrax vs. RelationBuildPartitionDesc In-reply-to: References: <20190313164232.GA5270@alvherre.pgsql> <7448.1552497345@sss.pgh.pa.us> <7961.1552498252@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 13 Mar 2019 14:07:27 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10787.1552501588.1@sss.pgh.pa.us> Date: Wed, 13 Mar 2019 14:26:28 -0400 Message-ID: <10788.1552501588@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: >> Dunno if that's related to hyrax's issue, though. > It's related in the sense that it's a leak, and any leak will tend to > run the system out of memory more easily, but what I observed was a > large leak into MessageContext, and that would be a leak into > CacheMemoryContext, so I think it's probably a sideshow rather than > the main event. OK, in that case it's definitely all the temporary data that gets created that is the problem. I've not examined your patch in great detail but it looks plausible for fixing that. I think that RelationBuildPartitionDesc could use some additional cleanup or at least better commenting. In particular, it's neither documented nor obvious to the naked eye why rel->rd_partdesc mustn't get set till the very end. As the complainant, I'm willing to go fix that, but do you want to push your patch first so it doesn't get broken? Or I could include your patch in the cleanup. regards, tom lane