| От | Michael Paquier |
|---|---|
| Тема | Re: Is there a memory leak in commit 8561e48? |
| Дата | |
| Msg-id | 20180501121000.GC25848@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Is there a memory leak in commit 8561e48? (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Список | pgsql-hackers |
On Mon, Apr 30, 2018 at 05:10:14PM -0400, Peter Eisentraut wrote:
> The memory leak can be fixed by adding a pfree().
>
> The example you show can be fixed by doing SPI cleanup in both
> transaction abort and exception return to main loop, similar to other
> cases that now have to handle these separately. Patch attached.
I have looked at the patch for some time and tested it, and the approach
looks good to me.
> +/*
> + * Clean up SPI state. Called on transaction end (of non-SPI-internal
> + * transactions) and when returning to the main loop on error.
> + */
> +void
> +SPICleanup(void)
> +{
> + if (_SPI_stack)
> + pfree(_SPI_stack);
> + _SPI_stack = NULL;
> + _SPI_stack_depth = 0;
> + _SPI_current = NULL;
> + _SPI_connected = -1;
> + SPI_processed = 0;
> + SPI_lastoid = InvalidOid;
> + SPI_tuptable = NULL;
> +}
If _SPI_stack is NULL, a quick exit path would make sense?
--
Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера