From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] FreeBSD problem under heavy load |
Date: | 1999-12-10 03:45:09 |
Message-ID: | 11460.944797509@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> I seem to run into a serious problem. With 6.5.x + FreeBSD 3.2, I get
> a core under heavy load (16 or more concurrent users). FreeBSD 2.2.x
> seems more stable but soon or later same thing happens. Examing a
> core, I found it segfaulted in hash_search().
I've been looking into this without much success. I cannot reproduce it
here under HPUX --- I ran pgbench for several hours without seeing any
problem. I also made another pass over the dynahash.c code looking for
portability bugs, but didn't find anything that looked promising. (The
code is ugly and fragile, but AFAICT it will work under existing usage
patterns.) It's quite possible the problem is elsewhere and dynahash is
just on the receiving end of a memory clobber ... but if so, we have
very little to go on in guessing where to look.
Can anyone else reproduce the problem? Does anything show up in the
postmaster log at or just before the crash?
regards, tom lane
PS: pgbench's configure fails on HPUX, because HP's compiler doesn't
like whitespace before #include. I modified configure.in like this:
AC_TRY_LINK([#include <sys/time.h>
#include <sys/resource.h>],
[struct rlimit rlim;
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-12-10 04:11:18 | pgsql web site busted? |
Previous Message | Tom Lane | 1999-12-10 02:42:30 | Re: [HACKERS] alter table crashes back end |