Lists: | pgsql-hackers |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jwieck(at)debis(dot)com (Jan Wieck) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] backend dies suddenly after a lot of error messages |
Date: | 1999-05-13 00:33:36 |
Message-ID: | 3125.926555616@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
>> Yeah, I'd say so --- all the memory used should get freed at transaction
>> end, but evidently it isn't happening.
>>
>> I still see it with 6.5-current sources. Will take a look.
Ah-ha, I think I see it: AtCommit_Memory releases memory in the blank
portal (by doing EndPortalAllocMode()). AtAbort_Memory forgets to do so.
Will commit this fix momentarily.
> I remember to have taken some but haven't found all the
> places. I think there's still something in tcop where the
> querytree list is malloc()'d.
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.
regards, tom lane
From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jwieck(at)debis(dot)com (Jan Wieck) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] backend dies suddenly after a lot of error messages |
Date: | 1999-05-13 01:09:10 |
Message-ID: | 3.0.1.32.19990512180910.00dd50e4@mail.pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(at)pacifier(dot)com>
Nature photos, on-line guides, and other goodies at
http://donb.photo.net