From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: remove unneeded pstrdup in fetch_table_list |
Date: | 2021-01-14 09:35:15 |
Message-ID: | CAA4eK1LSkGezxcORxDcS=RcVL9NnHZKs_GsXUJWw+RX73OuYFg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 14, 2021 at 10:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Michael Paquier <michael(at)paquier(dot)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.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-01-14 09:52:12 | Re: Yet another fast GiST build |
Previous Message | Erik Rijkers | 2021-01-14 09:24:27 | Re: proposal: schema variables |