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
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 |
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 |