Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info() - Mailing list pgsql-hackers

From Yongtao Huang
Subject Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()
Date
Msg-id CAOe1Go2JGmEOj-dUPrgQbWhN766vucN--Y3fkuHrTZz7dFmKZQ@mail.gmail.com
Whole thread Raw
In response to Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()
List 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@paquier.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

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans
Next
From: Tom Lane
Date:
Subject: Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()