Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info() |
| Дата | |
| Msg-id | 2914135.1705725261@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info() (Yongtao Huang <yongtaoh2022@gmail.com>) |
| Ответы |
Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()
|
| Список | pgsql-hackers |
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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера