"PostgreSQL Bugs List" <[EMAIL PROTECTED]> 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:
<snip>
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.
Sincerely, Tomi Orava
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
