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

Поиск
Список
Период
Сортировка
От Yongtao Huang
Тема Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()
Дата
Msg-id CAOe1Go1AC3iDiMUa17Pn0DBkbeNL=muu79E7Ce_fgX+_oEQPtQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

>  So whatever it leaks will be released at the transaction end.

I learned it. thank you very much for your explanation.

Regards,
Yongtao Huang

Tom Lane <tgl@sss.pgh.pa.us> 于2024年1月20日周六 12:34写道:
Yongtao Huang <yongtaoh2022@gmail.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Create shorthand for including all extra tests