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

Re: Memory leak in vac_update_relstats ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory leak in vac_update_relstats ?
Date: 2007-07-20 18:18:57
Message-ID: 11932.1184955537@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On 7/20/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>> It's palloc'd in the current memory context, so it's not serious.

> Right. But may be for code completeness, we should add that
> missing heap_freetuple.

Personally I've been thinking of mounting an effort to get rid of
unnecessary pfree's wherever possible.  Particularly in user-defined
functions, "cleaning up" at the end is a waste of code space and
cycles too, because they're typically called in contexts that are
going to be reset immediately afterward.

In the case of vac_update_relstats, it's called only once per
transaction, so there's certainly no point in being a neatnik.
Stuff you need to worry about is functions that might be called
many times in the same memory context.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bill MoranDate: 2007-07-20 19:28:25
Subject: Solved? Re: 8.2.4 signal 11 with large transaction
Previous:From: Scott MarloweDate: 2007-07-20 18:11:49
Subject: Re: 8.2.4 signal 11 with large transaction

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