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

From Michael Paquier
Subject Re: Is there a memory leak in commit 8561e48?
Date
Msg-id 20180501121000.GC25848@paquier.xyz
Whole thread Raw
In response to Re: Is there a memory leak in commit 8561e48?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Next
From: Peter Eisentraut
Date:
Subject: Re: lazy detoasting