Re: Double linking MemoryContext children

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Jan Wieck <jan(at)wi3ck(dot)info>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Double linking MemoryContext children
Date: 2015-09-12 15:35:59
Message-ID: 1137648579.1123841.1442072159630.JavaMail.yahoo@mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <jan(at)wi3ck(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-09-12 15:51:30 Re: Double linking MemoryContext children
Previous Message Takashi Horikawa 2015-09-12 14:42:37 Re: Partitioned checkpointing