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

Re: SRF memory leaks

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SRF memory leaks
Date: 2008-02-27 20:28:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
> Negative refcount does not prove that the SRF itself hasn't
> still got a pointer to the tupdesc.

That sounds quite bizarre. The SRF has already finished execution at
this point, so keeping a pointer to the tupledesc around would only make
sense if you wanted to use that tupledesc on a *subsequent* invocation
of the SRF. The SRF would need to store the pointer in a static
variable, too, and it wouldn't have an easy way to distinguish between
repeated calls to the SRF within the same query and in different queries
(since in the latter case the TupleDesc will be long gone anyway). I
can't see why anyone would want to do this.

> Can't we fix it so that the tupdesc is allocated in the new special
> context (at least in the primary code paths), and then no explicit
> free is needed?

As I said earlier, the tupdesc is explicitly allocated in the per-query
context by the SRFs themselves. If by "primary code paths", you mean
"SRFs in the main source tree", then sure, we can make arbitrary changes
to those. That won't help out-of-tree SRFs though.


In response to


pgsql-patches by date

Next:From: Peter EisentrautDate: 2008-02-27 20:32:43
Subject: Re: DTrace probe patch for OS X Leopard
Previous:From: Tom LaneDate: 2008-02-27 20:07:25
Subject: Re: SRF memory leaks

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