Re: Is there a memory leak in commit 8561e48? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Is there a memory leak in commit 8561e48?
Date
Msg-id f2dfa76b-83e8-75dc-3a75-379ed62b1ded@2ndquadrant.com
Whole thread Raw
In response to Re: Is there a memory leak in commit 8561e48?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses 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>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Clock with Adaptive Replacement
Next
From: Peter Eisentraut
Date:
Subject: EXECUTE does not process parameters