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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Is there a memory leak in commit 8561e48?
Дата
Msg-id f2dfa76b-83e8-75dc-3a75-379ed62b1ded@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Is there a memory leak in commit 8561e48?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: Is there a memory leak in commit 8561e48?  (Michael Paquier <michael@paquier.xyz>)
Re: Is there a memory leak in commit 8561e48?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 4/27/18 02:44, Andrew Gierth wrote:
>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
>  Tom> I would bet money that that "_SPI_current->internal_xact" thing is
>  Tom> wrong/inadequate.
> 
> In particular this looks wrong to me: after doing:
> 
> do $$
>   begin
>     execute 'declare foo cursor with hold for select 1/x as a from (values (1),(0)) v(x)';
>     commit;  -- errors within the commit
>   end;
> $$;
> ERROR:  division by zero
> CONTEXT:  PL/pgSQL function inline_code_block line 1 at COMMIT
> 
> the SPI stack is not cleaned up at all, and _SPI_connected is >= 0 even
> when back at the main backend command loop.

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Clock with Adaptive Replacement
Следующее
От: Peter Eisentraut
Дата:
Сообщение: EXECUTE does not process parameters