On 09/11/2015 09:58 AM, Tom Lane wrote:
Jan Wieck <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
