At 09:39 PM 5/12/99 -0400, Tom Lane wrote:
>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.
AOLServer, in particular, will keep a backend alive
forever unless the site goes idle for (typically)
some minutes. In this way, no overhead for backend
start-up is suffered by a busy site. AOLServer manages
the threads associated with particular http connections,
while the (typically) tcl scripts servicing the connections
ask for, use, and release database handles (the tcl
interpreter runs inside the server) . Each handle
is a connection to the db backend, and these connections
get passed around by the server to various threads as
they're released by tcl "ns_db releasehandle" calls.
So ... ANY permament memory leak by the backend will tear things
down eventually. "Randomly", from the sysadmin's point of view.
Don't feel bad, I know of one very busy Oracle site
that kicks things down once every 24 hrs in the
dead of night for fear of cumulative leaks or, well,
any of a number of imaginable db problems :)
>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...).
Relatively harmless in the environment I'm describing...
> I'm hoping that we can make a serious dent
>in that class of problem for release 6.6.
Still worth getting rid of, though!
>I believe that all the Postgres developers have a bedrock commitment
>to making the system as stable and bulletproof as we can.
Yes, I've gathered that in my reading of this group over the
last three days, and in my reading of older posts.
And y'all have fixed that other horrible bug from the
web service POV: table-level locking. Ugh. I'd given up
on using postgres for my project until I learned that 6.5
doesn't suffer from this limitation.
>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...
Memory's cheap, but not THAT cheap :)
OK, I'll go back to lurking again. Keep up the good work,
folks.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at
http://donb.photo.net
