Don Baccus <dhogaza@pacifier.com> writes:
> I think you may've just slammed a stake through the
> heart of a very significant bug
Thanks for the compliment :-). You might actually be right;
this bug could go a long way towards explaining why some people
find Postgres very reliable and others don't. The first group's
apps don't tend to provoke any SQL errors, and/or don't try to
continue running with the same backend after an error.
> 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.
We're aware of a number of memory-leak type problems, although
most of them are just temporary leakage situations (the memory
will eventually be freed, if you have enough memory to complete
the transaction...). I'm hoping that we can make a serious dent
in that class of problem for release 6.6.
I believe that all the Postgres developers have a bedrock commitment
to making the system as stable and bulletproof as we can. But it
takes time to root out the subtler bugs. I got lucky tonight ;-)
> 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 was measuring about 4K per cycle for a trivial parsing error,
like feeding "garbage;" to the backend repeatedly. It could be
a *lot* more depending on how much work got done before the error
was detected. Worst case you might lose megabytes...
regards, tom lane
