Re: Proposal for fixing intra-query memory leaks
От | Peter Eisentraut |
---|---|
Тема | Re: Proposal for fixing intra-query memory leaks |
Дата | |
Msg-id | Pine.LNX.4.21.0005020049550.389-100000@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: Proposal for fixing intra-query memory leaks
|
Список | pgsql-hackers |
Thanks for the timely introduction to memory contexts btw. :) > 1. There will be two kinds of contexts, "permanent" and "temporary". Rather than making this an explicit distinction you could simply (hah) make the transaction initiating command create a memory context under Top and store a pointer to it in a global variable. Then per tuple contexts, etc. are created as a child thereof. The transaction ending commands would then destroy that context again. I guess this is sort of what you were planning anyway but I just wanted to throw in that specially treating this "everything lives and dies with the transaction" attitude is not the be-all-end-all, IMHO. ("Statement" would be better than "transaction" in many cases anyway.) > Functions that return pass-by-reference values will be required always > to palloc the returned space in the caller's memory context (ie, the > context that was CurrentMemoryContext at the time of call). It is not > OK to pass back an input pointer, even if we are returning an input value > verbatim, because we do not know the lifespan of the context the input > pointer points to. ISTM that you can have the compiler help you here if you separate input and output values in the function manager design. E.g., if you define the function signature like void my_func(const fmgr_in_t * in, fmgr_out_t * out); then you establish the fact that copying is required. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: