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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yongtao Huang <yongtaoh2022(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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:34:21
Message-ID: 2914135.1705725261@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yongtao Huang <yongtaoh2022(at)gmail(dot)com> writes:
> (1) I think *pfree(pub_names.data)* is necessary.

Really?

It looks to me like copy_table, and thence fetch_remote_table_info,
is called once within a transaction. So whatever it leaks will be
released at transaction end. This is a good thing, because it's
messy enough that I seriously doubt that there aren't other leaks
in it, or that it'd be practical to expect that it can be made
to never leak anything.

If anything, I'd be inclined to remove the random pfree's that
are in it now. It's unlikely that they constitute a net win
compared to allowing memory context reset to clean things up.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2024-01-20 05:21:49 Re: Synchronizing slots from primary to standby
Previous Message Yongtao Huang 2024-01-20 04:08:52 Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()