Glauco Torres <torres.glauco@xxxxxxxxx> writes: > Today I left to generate more core-dump, follow the return, > (gdb) bt > #0 tbm_comparator (left=left@entry=0x1d5ca08, right=right@entry=0x3acdb70) > at tidbitmap.c:1031 > #1 0x0000000000801268 in med3 (a=0x1d5ca08 "\350>\337\001", b=0x3acdb70 > <Address 0x3acdb70 out of bounds>, c=0x583ecd8 <Address 0x583ecd8 out of > bounds>, cmp=0x603ca0 <tbm_comparator>) at qsort.c:107 > #2 0x0000000000801621 in pg_qsort (a=0x1d5ca08, n=<optimized out>, > n@entry=10477, > es=es@entry=8, cmp=cmp@entry=0x603ca0 <tbm_comparator>) at qsort.c:157 > #3 0x0000000000604a7b in tbm_begin_iterate (tbm=tbm@entry=0x1dd8a00) at > tidbitmap.c:635 Oh ho! I was wondering to myself "if pg_qsort is broken, why isn't his system falling over everywhere?". The answer evidently is "yes, it is falling over everywhere". This symptom looks pretty much like what you had before, ie far-out-of-range addresses getting passed to med3(), but the qsort call site is completely different. Since you've eliminated the idea that the executable file per se is different from your working servers, I think we're now down to the conclusion that there's something flaky about the hardware on this server. Maybe it's misexecuting integer divide every so often --- though it's hard to guess why only pg_qsort would be affected. regards, tom lane
