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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "jian(dot)long(at)i-soft(dot)com(dot)cn" <jian(dot)long(at)i-soft(dot)com(dot)cn>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is there a memory leak in commit 8561e48?
Date: 2018-05-01 12:10:00
Message-ID: 20180501121000.GC25848@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-05-01 14:04:38 Re: lazy detoasting
Previous Message Peter Eisentraut 2018-05-01 11:50:04 Re: Remove mention in docs that foreign keys on partitioned tables are not supported