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 1fonZE-00015R-0x for pgsql-bugs@arkaria.postgresql.org; Sun, 12 Aug 2018 10:25:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fonZC-0007jK-2y for pgsql-bugs@arkaria.postgresql.org; Sun, 12 Aug 2018 10:25:46 +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 1fonZB-0007jD-Px for pgsql-bugs@lists.postgresql.org; Sun, 12 Aug 2018 10:25:45 +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 1fonZ9-0000dQ-68 for pgsql-bugs@lists.postgresql.org; Sun, 12 Aug 2018 10:25:44 +0000 Received: from [192.168.127.1] (port=20761 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 1fonZ6-0003vn-1m; Sun, 12 Aug 2018 10:25:40 +0000 Received: from [127.0.0.1] (port=40587 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1fonZ5-000Bdf-DN; Sun, 12 Aug 2018 10:25:39 +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 12:02:31 +0200") Message-ID: <87bma77v67.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> <87k1ow6o7i.fsf@news-spur.riddles.org.uk> <87ftzk6jw2.fsf@news-spur.riddles.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Sun, 12 Aug 2018 11:25:39 +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: >> No, tuplestore_putvalues is only responsible for the memory it >> allocates itself, which belongs to the tuplestore, it has nothing to >> do with the memory allocated by its caller - and XmlTableGetValue >> does quite a few allocations. Pavel> Maybe I used wrong words. Sorry, my English lang is not good. Pavel> In master tfuncLoadRows switch to tstate->perValueCxt. You Pavel> change it by switch econtext->ecxt_per_tuple_memory what is Pavel> wrong I thing. Pavel> If we don't change memory context, we will stay inside Pavel> perValueCxt. And this context will be cleaned outside. Yes, but it won't be cleaned up until _all_ the rows from a single call have been generated, which means that the allocations from GetValue have been (uselessly) accumulating during this time, wasting memory. We do need a context that is reset for every output row, as perValueCxt used to be. I don't see why this is even in question. >> Before, you were using perValueCxt and resetting it once per GetValue >> call. Since my patch takes perValueCxt to use for another purpose >> instead, it needs to be replaced, and econtext->ecxt_per_tuple_memory >> is suitable for the job (and consistent with functionscan). Pavel> I think so using cxt_per_tuple_memory is not necessary - and my Pavel> patch is working too. Working, just using more memory than it needs to. Pavel> Just I removed MemoryContextReset(tstate->perValueCxt) after Pavel> tuplestore_putvalues. It is possible, because Pavel> tstate->perValueCxt is cleaned immediately in caller Pavel> tfuncFetchRows function. But that's not "immediately" because tfuncLoadRows is looping over the FetchRow call, and calling GetValue for each column in that row, and in your version it is _not cleaning up memory in that loop_. -- Andrew (irc:RhodiumToad)