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

Re: Followup on the UnixWare Optimizer bug.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Larry Rosenman" <ler(at)lerctr(dot)org>
Cc: "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Followup on the UnixWare Optimizer bug.
Date: 2005-08-25 04:37:24
Message-ID: 24121.1124944644@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-08-25 05:02:40
Subject: Re: Followup on the UnixWare Optimizer bug.
Previous:From: Bruce MomjianDate: 2005-08-25 03:53:37
Subject: Re: [HACKERS] Followup on the UnixWare Optimizer bug.

pgsql-patches by date

Next:From: Tom LaneDate: 2005-08-25 05:02:40
Subject: Re: Followup on the UnixWare Optimizer bug.
Previous:From: Bruce MomjianDate: 2005-08-25 03:53:37
Subject: Re: [HACKERS] Followup on the UnixWare Optimizer bug.

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