Freeing memory in native extension in case of error

Started by Gabriel Furstenheim Milerudalmost 9 years ago3 messagesgeneral
Jump to latest
#1Gabriel Furstenheim Milerud
furstenheim@gmail.com

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Gabriel Furstenheim Milerud (#1)
Re: Freeing memory in native extension in case of error

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#3Gabriel Furstenheim Milerud
furstenheim@gmail.com
In reply to: Tom Lane (#2)
Re: Freeing memory in native extension in case of error

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general