Re: Double linking MemoryContext children - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Double linking MemoryContext children
Date
Msg-id 1137648579.1123841.1442072159630.JavaMail.yahoo@mail.yahoo.com
Whole thread Raw
In response to Re: Double linking MemoryContext children  (Jan Wieck <jan@wi3ck.info>)
Responses Re: Double linking MemoryContext children  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Double linking MemoryContext children  (Jan Wieck <jan@wi3ck.info>)
List pgsql-hackers
Jan Wieck <jan@wi3ck.info> wrote:

>>> On 09/11/2015 09:38 AM, Tom Lane wrote:
>>>> Seems less invasive to fix SPI to delete in the opposite order?

> 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.

I guess the question is whether to add a pointer for each memory
context to give the MemoryContextSetParent() function O(1)
performance characteristics or add comments in front of this
function to document how callers should organize their code to
avoid O(N^2) performance.  I generally prefer that callers of such
a function need not be that aware of implementation details, so I
would prefer the former.

On the other hand, a grep indicates that there are two places that
MemoryContextData.nextchild is set (and we therefore probably need
to also set the new field), and Jan's proposed patch only changes
one of them.  If we do this, I think we need to change both places
that are affected, so ResourceOwnerCreate() in resowner.c would
need a line or two added.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Takashi Horikawa
Date:
Subject: Re: Partitioned checkpointing
Next
From: Tom Lane
Date:
Subject: Re: Double linking MemoryContext children