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

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jan Urbański <wulczer(at)wulczer(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Fix plpgsql to release SPI plans when a function or DO block is
Date: 2011-03-31 09:43:26
Message-ID: 4D944CBE.1050307@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On 31.03.2011 12:30, Jan Urbański wrote:
> On 31/03/11 07:35, Heikki Linnakangas wrote:
>> On 30.03.2011 21:21, Jan Urbański wrote:
>>> Valgrind showed me the way. PFA a trivial patch to avoid leaking a
>>> PLyProcedure struct in inline blocks.
>>
>> Hmm, any reason the PLyProcedure struct needs to be allocated in
>> TopMemoryContext in the first place? Could you palloc0 it in a
>> shorter-lived context, or even better, just allocate it in stack?
>
> Yeah, you're right, you can keep it on the stack.
>
>> PS. I don't think the volatile qualifier in 'proc' is in necessary. The
>> variable is not changed in PG_TRY-block.
>
> That always confuses me, but I guess you're right, the variable does not
> change, only the memory it points to.

Ok then, committed.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

pgsql-hackers by date

Next:From: Noah MischDate: 2011-03-31 10:06:49
Subject: Re: BUG #5856: pg_attribute.attinhcount is not correct.
Previous:From: Jan UrbańskiDate: 2011-03-31 09:30:29
Subject: Re: Re: [COMMITTERS] pgsql: Fix plpgsql to release SPI plans when a function or DO block is

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2011-03-31 10:41:35
Subject: pgsql: Increase SHMEM_INDEX_SIZE from 32 to 64. We're currently at 40e
Previous:From: Heikki LinnakangasDate: 2011-03-31 09:43:01
Subject: pgsql: Don't leak the temporary PLyProcedure struct we create forinlin

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