Horton

Re: pgsql: Fix plpgsql to release SPI plans when a function or DO block is

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: pgsql-committers@postgresql.org
Date: 2011-03-28T13:21:43Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix plpgsql to release SPI plans when a function or DO block is freed.

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 27.03.2011 19:51, Tom Lane wrote:
>> Fix plpgsql to release SPI plans when a function or DO block is freed.

> I was quite surprised by the way you did this. Instead of adding all 
> that code to traverse the PLpgSQL_stmt tree (that we'll have to remember 
> to keep up-to-date), can't we just have a list of cached plans in 
> PLpgSQL_function? As attached.

The code I added is a direct rip-off of the adjacent function tree
dumping code, which we've had no trouble keeping up-to-date.  (I checked
it as I went through, and it did not appear to be missing any cases.)
I'm unconvinced that adding a separate new mechanism to track the
function's SPI plans would be more easily maintainable or less prone to
oversights.  Also, what if we come up with another resource that has to
be explicitly released here?  The tree walk won't require additional
mechanism for that.

			regards, tom lane