Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()

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

In response to

Responses

Browse pgsql-hackers by date

  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