From: | Yongtao Huang <yongtaoh2022(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info() |
Date: | 2024-01-20 04:08:52 |
Message-ID: | CAOe1Go2JGmEOj-dUPrgQbWhN766vucN--Y3fkuHrTZz7dFmKZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for your review.
(1) I think *pfree(pub_names.data)* is necessary.
(2) Agree with you. Considering that the new function is only called
twice, not encapsulating it into a function is not a huge problem.
Best wishes
Yongtao Huang
Michael Paquier <michael(at)paquier(dot)xyz> 于2024年1月20日周六 11:13写道:
> On Fri, Jan 19, 2024 at 10:42:46PM +0800, Yongtao Huang wrote:
> > This patch fixes two things in the function fetch_remote_table_info().
> >
> > (1) *pfree(pub_names.data)* to avoid potential memory leaks.
>
> True that this code puts some effort in cleaning up the memory used
> locally.
>
> > (2) 2 pieces of code can do the same work,
> > ```
> > I wanna integrate them into one function `make_pubname_list()` to make
> the
> > code neater.
>
> It does not strike me as a huge problem to let the code be as it is on
> HEAD when building the lists, FWIW, as we are talking about two places
> and there is clarity in keeping the code as it is.
> --
> Michael
>
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-potential-memory-leak-in-tablesync.c.patch | application/octet-stream | 747 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-01-20 04:34:21 | Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info() |
Previous Message | vignesh C | 2024-01-20 03:35:15 | Re: Prefetch the next tuple's memory during seqscans |