Re: Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset
Date
Msg-id 878ufk6ioo.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> We've discussed doing $SUBJECT off and on for nearly ten years,Tom> the oldest thread I could find about it being
here:Tom>http://www.postgresql.org/message-id/flat/1186435268.16321.37.camel@dell.linuxdev.us.dell.comTom> It's come up
againevery time we found another leak of dead childTom> contexts, which happened twice last year for example.  And
thatTom>patch I'm pushing for "expanded" out-of-line objects really needsTom> this to become the default behavior
anywherethat we can detoastTom> objects.
 

So, this is also changing (indirectly) the effect of ReScanExprContext
so that deletes child contexts too. In the grouping sets work I noticed
I had to explicitly add some MemoryContextDeleteChildren after
ReScanExprContext in order to clean up properly; this obviously makes
that redundant.

(that looks like another data point in favour of this change)

I guess the only question is whether anything currently relies on
ReScanExprContext's current behavior.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Fabrízio de Royes Mello
Date:
Subject: Add CINE for ALTER TABLE ... ADD COLUMN
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Reduce pinning in btree indexes