Tom Lane wrote:
> "PostgreSQL Bugs List" <pgsql-bugs(at)postgresql(dot)org> writes:
>>It seems that MnoGoSearch 3.2.17 is capable of crashing postgresql 7.4.2
>>repeatedly every once in a while on Amd Athlon/Fedora Core 2.
>>The gdb trace:
> This isn't super helpful since some of the passed arguments are
> evidently clobbered already; it's hard to tell which values to trust.
> I was initially going to say that the ridiculous len2 argument to
> varstr_cmp suggests corrupt data, but seeing that the same value appears
> in several places on the trace (some in hex), I'm not sure if it's real
> or if gdb is confused. You might try rebuilding the backend with a
> lower optimization level so as to get a more reliable stack trace.
> Note that what is happening here is a comparison between an index key
> value being inserted and a key value already in the index. So one
> possible explanation is that the previously stored value is corrupt
> due to memory or disk problems. Have you run any hardware diagnostics?
> Can you reproduce the problem on another machine?
First of all, thank you very much for your extremely fast response.
It seems that you were right about your assumptions of broken hardware,
as I have changed an old Silicon Image 680 PCI-ide card (that has been in
use for several years though) to Promise 20267 ide-card and interestingly
there has been not been a single crash since last friday evening
(I did change the ide-disks without any success, but just couldn't believe
that there might be a problem with ide-controller).
I'm very happy to get see that postgresql is OK and the system is running :)
Unfortunately, I do think that there is something wrong with Sil680 driver
in 2.4.2x linux kernels, but thats about it for postgresql's sake.
In response to
pgsql-bugs by date
|Next:||From: Hebert, Caroline||Date: 2004-06-21 07:18:07|
|Subject: ECPG doesn't return the correct length for an empty |
|Previous:||From: Tom Lane||Date: 2004-06-20 19:26:34|
|Subject: Re: Hangs on Semop |