Thread
-
Re: [HACKERS] VACUUM ANALYZE problem on linux
Tom Lane <tgl@sss.pgh.pa.us> — 1999-03-15T15:18:22Z
Oleg Broytmann <phd@sun.med.ru> writes: > To remind of the problem - I have a problem running VACUUM ANALYZE on a > glibc2 linux (Debian 2.0). On solaris it is Ok (and I got a report it is Ok > on HP-UX). > Here is the traceback. The problem is in strcoll, don't understand why. > Program received signal SIGSEGV, Segmentation fault. > 0x40119587 in strcoll () > (gdb) where > #0 0x40119587 in strcoll () > #1 0x816cadd in varstr_cmp (arg1=0x4020fccc " ", len1=0, > arg2=0x8268604 " ", len2=0) at varlena.c:511 > #2 0x816b31d in bpcharlt (arg1=0x4020fcc8 "\n", arg2=0x8268600 "\n") > at varchar.c:504 Sure looks like strcoll is broken on your platform. Build a little test program and see if strcoll("", "") coredumps ... if the traceback is accurate, that's what was getting passed to it. BTW, why in the world is varstr_cmp written to duplicate the strings it's passed, rather than just handing them off to strcoll() as-is? regards, tom lane -
Re: [HACKERS] VACUUM ANALYZE problem on linux
Oleg Broytmann <phd@sun.med.ru> — 1999-03-15T15:25:13Z
Hi! On Mon, 15 Mar 1999, Tom Lane wrote: > Sure looks like strcoll is broken on your platform. Build a little test > program and see if strcoll("", "") coredumps ... if the traceback is > accurate, that's what was getting passed to it. Will test it... > BTW, why in the world is varstr_cmp written to duplicate the strings > it's passed, rather than just handing them off to strcoll() as-is? I got the code... No, I didn't "got" it - I found the code. Initially it was written by Oleg Bartunov, and I extended it a bit for all char types (initial code worked only with "text" type). > regards, tom lane > Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they just GOSUB without RETURN. -
Re: [HACKERS] VACUUM ANALYZE problem on linux
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-03-15T15:34:13Z
> Oleg Broytmann <phd@sun.med.ru> writes: > > To remind of the problem - I have a problem running VACUUM ANALYZE on a > > glibc2 linux (Debian 2.0). On solaris it is Ok (and I got a report it is Ok > > on HP-UX). > > Here is the traceback. The problem is in strcoll, don't understand why. > > > Program received signal SIGSEGV, Segmentation fault. > > 0x40119587 in strcoll () > > (gdb) where > > #0 0x40119587 in strcoll () > > #1 0x816cadd in varstr_cmp (arg1=0x4020fccc " ", len1=0, > > arg2=0x8268604 " ", len2=0) at varlena.c:511 > > #2 0x816b31d in bpcharlt (arg1=0x4020fcc8 "\n", arg2=0x8268600 "\n") > > at varchar.c:504 > > Sure looks like strcoll is broken on your platform. Build a little test > program and see if strcoll("", "") coredumps ... if the traceback is > accurate, that's what was getting passed to it. > > BTW, why in the world is varstr_cmp written to duplicate the strings > it's passed, rather than just handing them off to strcoll() as-is? It appears he is unsure whether the string is null-terminated, and he is right in not assuming that. We have strncmp, but there is no strncoll(). -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -
Re: [HACKERS] VACUUM ANALYZE problem on linux
Oleg Broytmann <phd@sun.med.ru> — 1999-03-15T15:51:32Z
On Mon, 15 Mar 1999, Tom Lane wrote: > Sure looks like strcoll is broken on your platform. Build a little test > program and see if strcoll("", "") coredumps ... if the traceback is > accurate, that's what was getting passed to it. #include <stdio.h> #include <string.h> int main() { printf("strcoll: %d\n", strcoll("", "")); return 0; } prints: "strcoll: 0". No core. > regards, tom lane > Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they just GOSUB without RETURN. -
Re: [HACKERS] VACUUM ANALYZE problem on linux
Oleg Broytmann <phd@sun.med.ru> — 1999-03-21T15:42:59Z
Hello! > > To remind of the problem - I have a problem running VACUUM ANALYZE on a > > glibc2 linux (Debian 2.0). On solaris it is Ok (and I got a report it is Ok > > on HP-UX). I have upgradede Debian 2.0 to 2.1 and the problem mysteriously gone away! I am using the word "mysteriously" because: -- I have not upgraded kernel (yet) - I am still running 2.0.34 -- I have not upgraded glibc2 - both 2.0 and 2.1 are based upon libc-2.0.7 -- I have not upgraded nor recompiled postgres. Yes, this fix my problem, but what next? It seems suspicious to me, so I can expect other glibc2-related problems. BTW, I already reported yet another problem with glibc2 - bug with complex join (actually, not so complex - 4 tables). I overcame the error by rewriting the query into correlated subquery with EXISTS. I'll test if Debian upgrade "mysteriously" fix the problem too. Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they just GOSUB without RETURN. -
Re: [HACKERS] VACUUM ANALYZE problem on linux
Oleg Broytmann <phd@sun.med.ru> — 1999-03-21T15:50:29Z
Hi! Followup to myself... On Sun, 21 Mar 1999, Oleg Broytmann wrote: > BTW, I already reported yet another problem with glibc2 - bug with > complex join (actually, not so complex - 4 tables). I overcame the error by > rewriting the query into correlated subquery with EXISTS. I'll test if > Debian upgrade "mysteriously" fix the problem too. No, the join still bugs (it return 0 rows, where rewrote query returns some number of rows, and these rows seems to me pretty good - either there is a bug in join or I rewrote the query in a wrong way, and got correct results :) Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they just GOSUB without RETURN.