Re: freefuncs.c is never called from anywhere!?
Any status on this?
I was rather bemused to discover just now that the node-freeing
functions in nodes/freefuncs.c are never called from anywhere;
in fact, the module hasn't got a single exported entry point!(I expect that freeObject() is supposed to be an external entry
point; perhaps it got demoted to a static during one of Bruce's
periodic get-rid-of-unreferenced-global-symbols passes.)So much for all that tedious labor to maintain the freeXXX functions
every time we update a node type ;-)Now I am not quite sure what to do. I was intending to use freeObject
to clean up rule qual/action trees during relcache flush --- up to now,
that cache data has been permanently leaked by any relcache flush
affecting a relation with rules. But if freefuncs.c hasn't actually
been used in a long time, it may well be suffering serious bit-rot.
I am worried about turning it on just before beta. I am especially
worried about turning it on for use only in a seldom-taken code path ---
if there are bugs in it, we may not find them until after release.Should I chicken out and let the memory leak persist until we start
7.1 development cycle? Or go for it and hope the code's OK?regards, tom lane
************
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found: 737.949186287@sss.pgh.pa.us
Any status on this?
Nothing done about it yet.
IIRC, some people were concerned about the fact that freeObject()
couldn't possibly cope with circular structures, multiply-linked
subexpressions, etc. I don't think that's a problem for my intended
use in the relcache --- the only structures I'll be freeing are ones
previously read in by the node-reading functions, and those aren't
going to have any surprises like that.
regards, tom lane
On Fri, 9 Jun 2000, Tom Lane wrote:
Any status on this?
Nothing done about it yet.
IIRC, some people were concerned about the fact that freeObject()
couldn't possibly cope with circular structures, multiply-linked
subexpressions, etc. I don't think that's a problem for my intended
use in the relcache --- the only structures I'll be freeing are ones
previously read in by the node-reading functions, and those aren't
going to have any surprises like that.
IMHO use separate memory context will better and more fast way than
freeObject(). I use this method in my suggested query cache and in the
SPI (in SPI_freeplan()) and it is very good (without potential leaks).
All in backend/nodes are (IMHO) very dificult keep up and recursion is
and not gratis feature too. (Homework: write PG in Fortran :-)
Karel
Karel Zak <zakkr@zf.jcu.cz> writes:
IIRC, some people were concerned about the fact that freeObject()
couldn't possibly cope with circular structures, multiply-linked
subexpressions, etc. I don't think that's a problem for my intended
use in the relcache --- the only structures I'll be freeing are ones
previously read in by the node-reading functions, and those aren't
going to have any surprises like that.
IMHO use separate memory context will better and more fast way than
freeObject().
A separate memory context for each relcache entry? I don't think so...
contexts aren't likely to be *that* cheap. Especially since I'd
probably need at least two contexts per relcache entry in order to do it
that way.
regards, tom lane
Karel Zak <zakkr@zf.jcu.cz> writes:
IIRC, some people were concerned about the fact that freeObject()
couldn't possibly cope with circular structures, multiply-linked
subexpressions, etc. I don't think that's a problem for my intended
use in the relcache --- the only structures I'll be freeing are ones
previously read in by the node-reading functions, and those aren't
going to have any surprises like that.IMHO use separate memory context will better and more fast way than
freeObject().A separate memory context for each relcache entry? I don't think so...
No. I mean _common_ for manipulation with query/plan tree.