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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to