On Mon, Mar 21, 2022 at 3:05 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Zhihong Yu <z...@yugabyte.com> writes: > >> I was looking at calls to bms_free() in PG code. > >> e.g. src/backend/commands/publicationcmds.c line 362 > >> bms_free(bms); > >> The above is just an example, there're other calls to bms_free(). > >> Since the bms is allocated from some execution context, I wonder why > this > >> call is needed. > >> > >> When the underlying execution context wraps up, isn't the bms freed ? > > Yeah, that's kind of pointless --- and the pfree(rfnode) after it is even > more pointless, since it'll free only the top node of that expression > tree. Not to mention the string returned by TextDatumGetCString, and > whatever might be leaked during the underlying catalog accesses. > > If we were actually worried about transient space consumption of this > function, it'd be necessary to do a lot more than this. It doesn't > look to me like it's worth worrying about though -- it doesn't seem > like it could be hit more than once per query in normal cases. > > regards, tom lane >
Thanks Tom for replying. What do you think of the following patch ? Cheers
rfcolumn-free.patch
Description: Binary data
