On 09/11/2015 09:58 AM, Tom Lane wrote:
> Jan Wieck <jan@wi3ck.info> writes:
>> On 09/11/2015 09:38 AM, Tom Lane wrote:
>>> Seems less invasive to fix SPI to delete in the opposite order?
>
>> That would assume that there are no other code paths that destroy memory
>> contexts out of LIFO order.
>
> Given that we've not seen this sort of problem reported in the dozen or
> more years the code has been like that, I'm a bit dubious that we need
> to worry about that. It's possible you're right that we need to expend
> more space in the MemoryContext lists --- but I'd like to see more than
> one example.
I added a bit of debug code to MemoryContextSetParent(), tracking loop
iterations per context name. This is what happens during "make check" of
current master:
name | count | not_first | iterations
--------------------------------------+--------+-----------+------------ CacheMemoryContext | 6271
| 2634 | 104846 ExecutorState | 222290 | 2951 | 7176 TopMemoryContext
| 28464 | 620 | 2716 SPI Proc | 8424 | 225 | 381
PortalMemory | 24616 | 31 | 291 TopTransactionContext | 19312 |
114 | 141 ExprContext | 3317 | 1 | 1
There was a total of 6,271 calls to MemoryContextSetParent() where the
old parent is the CacheMemoryContext. For 2,634 of those the context is
not parent->firstchild and this lead to 104,846 loop iterations total.
The remaining numbers indicate that other contexts are mostly used in
the intended fashion, but not strictly. This means there is definitely
potential for more edge cases, similar to the SPI example above.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
