Thread: [GENERAL] Freeing memory in native extension in case of error
[GENERAL] Freeing memory in native extension in case of error
From
Gabriel Furstenheim Milerud
Date:
Hi, I've written an extension in C to sum jsonb. For that I use the jsonbiterator defined in https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/jsonb_util.c#L743 In the comments of JsonbIteratorNext it states: 'Callers in such a scenario, that are particularly sensitive to leaking memory in a long-lived context may walk the ancestral tree from the final iterator we left them with to its oldest ancestor, pfree()ing as they go' In the extension that I've written, I sometimes stop in the middle of an iteration, but only to raise an error (if the json contains a not numeric value), with 'ereport(ERROR, ...' Do I have to free the memory in that case? According to this guide to write extensions (http://big-elephants.com/2015-10/writing-postgres-extensions-part-i/) it wouldn't be necessary because 'Memory allocated by palloc will be freed automatically at the end of each transaction'. So if I understand it correctly I wouldn't have to. Thanks
Gabriel Furstenheim Milerud <furstenheim@gmail.com> writes: > I've written an extension in C to sum jsonb. For that I use the > jsonbiterator defined in > https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/jsonb_util.c#L743 > In the comments of JsonbIteratorNext it states: 'Callers in such a > scenario, that are particularly sensitive to leaking memory in a > long-lived context may walk the ancestral tree from the final iterator > we left them with to its oldest ancestor, pfree()ing as they go' > In the extension that I've written, I sometimes stop in the middle of > an iteration, but only to raise an error (if the json contains a not > numeric value), with 'ereport(ERROR, ...' > Do I have to free the memory in that case? I wouldn't bother, assuming that it's all in the short-lived query context (the one that's current when your function is called). Error cleanup will flush that context automatically. Really, for memory in that context, it's unlikely to matter even if you are sloppy and leak memory on normal non-error return. That context will get reset after each row processed by the query anyway. It's only if you're trying to cache data across rows, or in even longer-lived ways, that you really need to be careful. regards, tom lane
Re: [GENERAL] Freeing memory in native extension in case of error
From
Gabriel Furstenheim Milerud
Date:
Great, thanks On 15 June 2017 at 22:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Gabriel Furstenheim Milerud <furstenheim@gmail.com> writes: >> I've written an extension in C to sum jsonb. For that I use the >> jsonbiterator defined in >> https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/jsonb_util.c#L743 > >> In the comments of JsonbIteratorNext it states: 'Callers in such a >> scenario, that are particularly sensitive to leaking memory in a >> long-lived context may walk the ancestral tree from the final iterator >> we left them with to its oldest ancestor, pfree()ing as they go' > >> In the extension that I've written, I sometimes stop in the middle of >> an iteration, but only to raise an error (if the json contains a not >> numeric value), with 'ereport(ERROR, ...' > >> Do I have to free the memory in that case? > > I wouldn't bother, assuming that it's all in the short-lived query > context (the one that's current when your function is called). > Error cleanup will flush that context automatically. > > Really, for memory in that context, it's unlikely to matter even > if you are sloppy and leak memory on normal non-error return. > That context will get reset after each row processed by the > query anyway. It's only if you're trying to cache data across > rows, or in even longer-lived ways, that you really need to be > careful. > > regards, tom lane