"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> I saw use of a couple of malloc (or Python specific malloc) calls the
> other day but I also seem to recall that, after consideration, I
> decided the memory needed to survive for the duration of the
> backend. Should I have created a new child of the top context and
> changed these malloc calls?
If there is truly no reason to release the memory before the backend
dies, then I see no reason to avoid malloc(). Basically what the memory
context stuff gives you is the ability to bunch allocations together and
release a whole tree of stuff for little work.
An example: currently, the plpgsql parser builds its parsed syntax tree
with a bunch of malloc's. It has no way to free a syntax tree, so that
tree lives till the backend exits, whether it's ever used again or not.
It would be better to build the tree via palloc's in a context created
specially for the specific function: then we could free the whole
context if we discovered that the function had gone away or been
redefined. (Compare what relcache does for rule syntaxtrees for rules
associated with relcache entries.) But right at the moment, there's no
mechanism to discover that situation, and so there's not now any direct
value in using palloc instead of malloc for plpgsql syntaxtrees. Yet
that's surely the direction to go in for the long term.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
