Re: remove unneeded pstrdup in fetch_table_list
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, "Hou,
Zhijie" <houzj.fnst@cn.fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Daniel Gustafsson <daniel@yesql.se>
Date: 2021-01-16T05:09:14Z
Lists: pgsql-hackers
On Thu, Jan 14, 2021 at 3:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Jan 14, 2021 at 10:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Michael Paquier <michael@paquier.xyz> writes: > > > On Thu, Jan 14, 2021 at 01:17:57AM +0000, Hou, Zhijie wrote: > > >>>> Thanks. I am thinking to backpatch this even though there is no > > >>>> problem reported from any production system. What do you think? > > > > > text_to_cstring() indeed allocates a new string, so the extra > > > allocation is useless. FWIW, I don't see much point in poking at > > > the stable branches here. > > > > Yeah, unless there's some reason to think that this creates a > > meaningful memory leak, I wouldn't bother back-patching. > > > > The only case where it might impact as per the report of Zhijie Hou is > where the user is subscribed to the publication that has a lot of > tables like Create Publication ... For All Tables. Even though for > such a case the memory consumed could be high but all the memory is > allocated in the Portal context and will be released at the statement > end. I was not sure if that could create a meaningful leak to any user > so to be on the safer side proposed to backpatch it. However, if > others don't think we need to backpatch this then I am fine doing it > just for HEAD. > Hearing no further suggestions, pushed just to HEAD. -- With Regards, Amit Kapila.
Commits
-
Remove unnecessary pstrdup in fetch_table_list.
- c95765f47673 14.0 landed