On Wed, 3 Dec 2008, Scott Marlowe wrote:
>> Having sent the process a SIGINT and inspected the logs, I now have a query
>> to explain. Looking at it, there is one single sort, and ten hash
>> operations, which would equate to 10GB, not 30GB. What is more worrying is
>> that now that the query has been stopped, the backend process is still
>> hanging onto the RAM.
>
> What's your setting for share_buffers, as that's likely what the
> backend is holding onto.
Shared buffers are set at 500MB, which is what all the other backends are
holding onto. It's just the one backend that is using 30GB. At the moment,
it is being swapped out, but the system seems responsive. We'll restart
the whole lot some time in the middle of the night when noone minds.
> Also, you should REALLY update to 8.3.5 as there are some nasty bugs
> fixed from 8.3.0 you don't want to run into. Who knows, you might be
> being bitten by one right now. Unlike other bits of software floating
> around, pgsql updates are bug fix / security fix only, with no major
> code changes allowed, since those go into the next release which is
> usually ~1 year later anyway.
It's possible, although I didn't see any relevant memory leaks in the
release notes. This is one of the only machines we have that has not been
upgraded, and it is on our schedule. Because it is running a slightly old
version of RedHat Fedora, upgrading involves more horribleness than our
sysadmin is willing to do on the fly with the server up.
Matthew
--
The email of the species is more deadly than the mail.
