Re: Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset
Date: 2015-02-27 05:19:37
Message-ID: 878ufk6ioo.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(dot)16321(dot)37(dot)camel(at)dell(dot)linuxdev(dot)us(dot)dell(dot)com
Tom> It's come up again every time we found another leak of dead child
Tom> contexts, which happened twice last year for example. And that
Tom> patch I'm pushing for "expanded" out-of-line objects really needs
Tom> this to become the default behavior anywhere that we can detoast
Tom> 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-02-27 05:30:47 Re: Reduce pinning in btree indexes
Previous Message Fabrízio de Royes Mello 2015-02-27 04:01:54 Add CINE for ALTER TABLE ... ADD COLUMN