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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Fix plpgsql to release SPI plans when a function or DO block is
Date: 2011-03-28 13:21:43
Message-ID: 3496.1301318503@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-03-28 13:35:27 pgsql: Get rid of links that don't work when building HISTORY.
Previous Message Jan Urbański 2011-03-28 10:21:25 Re: Re: [COMMITTERS] pgsql: Fix plpgsql to release SPI plans when a function or DO block is

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-28 13:25:32 Re: alpha5
Previous Message Simon Riggs 2011-03-28 13:11:33 Re: Additional options for Sync Replication