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 <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1fos1v-0004fb-FC
	for pgsql-bugs@arkaria.postgresql.org; Sun, 12 Aug 2018 15:11:43 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1fos1r-0006Ds-Oo
	for pgsql-bugs@arkaria.postgresql.org; Sun, 12 Aug 2018 15:11:39 +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 <tgl@sss.pgh.pa.us>)
	id 1fos1r-0006Dk-FD
	for pgsql-bugs@lists.postgresql.org; Sun, 12 Aug 2018 15:11:39 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1fos1o-0006oB-Rp
	for pgsql-bugs@lists.postgresql.org; Sun, 12 Aug 2018 15:11:38 +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 w7CFBWYD017554;
	Sun, 12 Aug 2018 11:11:33 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
cc: Pavel Stehule <pavel.stehule@gmail.com>, pgsql-bugs@lists.postgresql.org,
        Alvaro Herrera <alvherre@2ndquadrant.com>
Subject: Re: BUG #15321: XMLTABLE leaks memory like crazy
In-reply-to: <877ekv7s9j.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>
 <CAFj8pRAm9cRuTf5STnX=0fGLpxhu7CR6GAj8LGq+iuw+NKXfPg@mail.gmail.com>
 <CAFj8pRBMpOn7X-N2PZKFtMK2UNjTahoArGmtMo1C7Az0x9Rzeg@mail.gmail.com>
 <87k1ow6o7i.fsf@news-spur.riddles.org.uk>
 <CAFj8pRD7bkGhn47wTw-CPhAQgH8OikezB=JrzVRsP_RAWH-scA@mail.gmail.com>
 <87ftzk6jw2.fsf@news-spur.riddles.org.uk>
 <CAFj8pRDWORKuuLEvFN-tMp06nuD5g_+yPAWWVW7umanoriEwwg@mail.gmail.com>
 <87bma77v67.fsf@news-spur.riddles.org.uk>
 <CAFj8pRDr74=wxRD68EGMS6Z90rTn4JOp6g9s_3BE37gtkJAX6A@mail.gmail.com>
 <877ekv7s9j.fsf@news-spur.riddles.org.uk>
Comments: In-reply-to Andrew Gierth <andrew@tao11.riddles.org.uk>
	message dated "Sun, 12 Aug 2018 12:18:07 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17552.1534086692.1@sss.pgh.pa.us>
Date: Sun, 12 Aug 2018 11:11:32 -0400
Message-ID: <17553.1534086692@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Precedence: bulk

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Attached patch is the same logic as before but with more comments.

This looks generally reasonable to me, but what's the point of doing
two MemoryContextReset calls in tfuncFetchRows?  Doing one at the
end should be sufficient to guarantee that the context is empty already
at the next call.

Also, I'd be inclined to rename "perValueCxt" to something else,
it's not really correctly named for this usage pattern.

			regards, tom lane