Re: Is there a memory leak in commit 8561e48?

Поиск
Список
Период
Сортировка
От 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: lazy detoasting