On 05/31/2011 10:46 PM, Mathew Samuel wrote:
> Thanks for your help, here are the results from running that you provided to me:
> $ egrep '^[^#[:space:]]' postgresql.conf |cut -d '#' -f 1
[snip]
OK, nothing interesting there. Thanks for posting it, though; I was
wondering if there might be a very high work_mem causing a swap storm or
something like that at the root of it.
> And as you anticipated, no core file was dumped on that system.
Given that it sounds like Tom knows what caused it, it turns out not to
matter much. Thanks for checking, though.
> It is quite possible that the system was under heavy load at the time as it is a heavily used system that would be
proneto periods of strong use. No monitoring (Cacti or otherwise) was active as far as I can gather.
Getting monitoring in place would be good, as it'll help you plan
capacity and identify overload.
> Not that this is any sort of solution but would one approach be to increase the statement_timeout to greater than 1
minute?I realize that this may hide the symptom but if the customer does hit this issue again I'm just seeing if there
isan option I can change to help prevent a reoccurrence.
Update. You're running an ancient point release. The current 8.2 release
is 8.2.21, so you are missing a *LOT* of bug fixes and small performance
fixes.
--
Craig Ringer