At 08:33 PM 5/12/99 -0400, Tom Lane wrote:
>That is a relatively minor leak, compared to leaking *all* memory
>allocated in the failed transaction, which is what it was doing until
>now :-(. But I think I will fix it anyway ... the code is awfully
>ugly, and it is still a leak.
I'm a lurker, a compiler writer who has just begun using
Postgres as the database engine behind a bird population
tracking project I'm putting up on the web on my own
time, on a linux box running AOLServer and, for now at
least, postgres.
In my researching postgres vs. paying Oracle (which didn't
seem too bad until I learned about their extra fees for
web sites and multiple-CPU boxes) vs. mySql etc, the one
biggest complaint I've run across when talking to people
running web sites backed by Postgres has been that the
back end starts dying after weeks ... days ... hours
depending on the type of site.
On questioning folks, it seemed pretty clear that in
some of these cases significant memory leaking was
causing the system to run out of memory.
And last week I managed to generate long sequences
of SQL that would eat available memory in about
15 minutes. I've been lurking around a couple of
these postgres lists trying to figure out whether
or not it was a known problem before making noise
about it.
So, imagine my pleasure at seeing this short thread
on the problem and, even better, the solution!
Well, if not the (only) leak, at least one very,
very serious memory leak. Just how many kb were
being leaked for each failed transaction?
I think you may've just slammed a stake through the
heart of a very significant bug causing a lot of
people seemingly unexplainable flakey back-end
behavior...this fix alone may do a lot to erase
the impression some have that postgres is not
reliable enough to support any web site based
on a large database with lots of transactions.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at
http://donb.photo.net
