Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fokx9-0002ay-LF for pgsql-bugs@arkaria.postgresql.org; Sun, 12 Aug 2018 07:38:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fokx5-0002GL-CT for pgsql-bugs@arkaria.postgresql.org; Sun, 12 Aug 2018 07:38:15 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fokx5-0002GE-37 for pgsql-bugs@lists.postgresql.org; Sun, 12 Aug 2018 07:38:15 +0000 Received: from lungold.riddles.org.uk ([82.68.208.19]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fokx1-0005MB-Ux for pgsql-bugs@lists.postgresql.org; Sun, 12 Aug 2018 07:38:13 +0000 Received: from [192.168.127.1] (port=15819 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1fokwx-0003lA-NW; Sun, 12 Aug 2018 07:38:07 +0000 Received: from [127.0.0.1] (port=57208 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1fokww-000AYA-UW; Sun, 12 Aug 2018 07:38:07 +0000 From: Andrew Gierth To: Pavel Stehule Cc: pgsql-bugs@lists.postgresql.org, Alvaro Herrera Subject: Re: BUG #15321: XMLTABLE leaks memory like crazy In-Reply-To: (Pavel Stehule's message of "Sun, 12 Aug 2018 09:21:12 +0200") Message-ID: <87k1ow6o7i.fsf@news-spur.riddles.org.uk> References: <153394403528.10284.7530399040974170549@wrigleys.postgresql.org> <87va8h7nyl.fsf@news-spur.riddles.org.uk> <87r2j57hdo.fsf@news-spur.riddles.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Sun, 12 Aug 2018 08:38:06 +0100 MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk >>>>> "Pavel" == Pavel Stehule writes: Pavel> + MemoryContextReset(tstate->perValueCxt); Pavel> + MemoryContextSwitchTo(tstate->perValueCxt); Pavel> + Pavel> PG_TRY(); Pavel> The reset of memory context is useless, because the reset of Pavel> perValueCxt is there already on the end of tfuncFetchRows Pavel> function It's overkill, yes, but it's also harmless because resetting a context that's not been touched since the last reset has very little overhead. Pavel> I don't understand to using tuple memory context We still need a per-result-tuple memory context otherwise we're leaking whatever memory got allocated in each GetValue call into the per-input-value context. (We can use our projection econtext's per-tuple memory for this because we haven't done any evaluation of output items for the current cycle yet at the point this code is reached.) Again, look at functionscan for how this is supposed to work. Pavel> When we are running under perValueCxt, then there changing Pavel> memory context is useless It's not useless at all; it's needed to avoid excess memory usage when a single XMLTABLE() call returns many rows. -- Andrew (irc:RhodiumToad)