Skip site navigation (1) Skip section navigation (2)

Patch for SPI subtransaction memory leakage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Patch for SPI subtransaction memory leakage
Date: 2006-11-03 05:40:53
Message-ID: 26365.1162532453@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
I noticed a gripe about plpgsql exceptions leaking memory:
http://archives.postgresql.org/pgsql-performance/2006-11/msg00032.php
(woulda been nice if he'd reported it more formally, but whatever.)

Some experimentation shows that there is indeed an issue, eg this
function leaks about 16K per iteration in HEAD:

create function fooey(int) returns void as $$
begin
  for n in 1..$1 loop
    begin
      perform 1/0;
    exception
      when others then null;
    end;
  end loop;
end$$ language plpgsql;

I came up with the attached patch that gets rid of the bulk of the leak
--- this particular example still leaks about 48 bytes/iteration due to
the two palloc's in exec_run_select(), which it doesn't get control back
to free.  It's hard to see dealing with that without a major rewrite of
plpgsql's memory management :-(

While this patch passes all the regression tests, I'm still a bit
nervous about whether it might free data that someone still wants
somewhere.  Anyone have any complicated PL functions or handwritten
SPI-using code they'd like to try it with?

			regards, tom lane

*** src/backend/executor/spi.c.orig	Tue Oct  3 23:16:22 2006
--- src/backend/executor/spi.c	Fri Nov  3 00:19:35 2006
***************
*** 254,259 ****
--- 254,272 ----
  				(errcode(ERRCODE_WARNING),
  				 errmsg("subtransaction left non-empty SPI stack"),
  				 errhint("Check for missing \"SPI_finish\" calls.")));
+ 
+ 	/*
+ 	 * If we are aborting a subtransaction and there is an open SPI context
+ 	 * surrounding the subxact, clean up to prevent memory leakage.
+ 	 */
+ 	if (_SPI_current && !isCommit)
+ 	{
+ 		/* free Executor memory the same as _SPI_end_call would do */
+ 		MemoryContextResetAndDeleteChildren(_SPI_current->execCxt);
+ 		/* throw away any partially created tuple-table */
+ 		SPI_freetuptable(_SPI_current->tuptable);
+ 		_SPI_current->tuptable = NULL;
+ 	}
  }
  
  

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-11-03 07:18:10
Subject: Re: Micro-doc patch for CREATE FUNCTION
Previous:From: Joachim WielandDate: 2006-11-03 03:57:21
Subject: Micro-doc patch for CREATE FUNCTION

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group