Re: freefuncs.c is never called from anywhere!? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: freefuncs.c is never called from anywhere!?
Date
Msg-id 200006091032.GAA05704@candle.pha.pa.us
Whole thread Raw
In response to freefuncs.c is never called from anywhere!?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: freefuncs.c is never called from anywhere!?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: Proposal: TRUNCATE TABLE table RESTRICT
Next
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: Re: Implementing STDDEV and VARIANCE