"Larry Rosenman" <ler@lerctr.org> forwards: > Also note that there appears to be a memory leak in the interval_**** > routines. For example interval_div() allocates a "result" Interval. > It eventually passes this result through to interval_justify_hours() which > allocates another Interval "result" and that "result" is what gets passed > back to caller on interval_div(). The 1st Interval allocated appears to be > left around.......
Just to clarify my discussion with Bruce: this is a leak from the point of view of these specific routines, but we do not care, because the memory is leaked in a short-lived palloc context that will soon be reset ("soon" being "the next tuple cycle" in most cases). We rely on this behavior in a lot of places --- for example, detoasting a toasted input datum leaks memory that in most places isn't explicitly cleaned up. Cleaning up just a dozen or so bytes is really not worth the cycles needed to do it. Despite that, I wouldn't have objected to Bruce's patch if it hadn't made the code noticeably more obscure. As a general rule, datatype-specific functions only need to be paranoid about not leaking memory if they may be invoked by index operations; btree indexes, at least, call such functions in a query-lifespan memory context. (I think GIST was recently fixed to not do this, but btree still does.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings