Re: Followup on the UnixWare Optimizer bug.

"Larry Rosenman" <ler(at)lerctr(dot)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