From: | Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk> |
---|---|
To: | szybist(at)boxhill(dot)com |
Cc: | maillist(at)candle(dot)pha(dot)pa(dot)us, hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Core dump in regression tests. |
Date: | 1998-08-31 19:19:29 |
Message-ID: | 199808311919.UAA01013@mtcc.demon.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas A. Szybist <szybist(at)boxhill(dot)com>
>
> >
> > If I compile backend/catalog with -O2 then the table creation is
> ^^^
> > OK. So it looks like it may be indexing.c, even with Bruce's
> > recent fixes.
>
> Do you mean -O0 here?
>
Yes, a typo, I used -O0 for this dir.
>
> I managed to get this running on a Solaris box. -O2 was not included
> by default (wonder why :)). I got a core dump when running initdb
> with -O2. I recompiled indexing.c without -O2, and it is much better.
> (I basically get the same results as under Linux.) I get the same
> core dumps that Keith is seeing with create function.
>
> So, both my Sparc boxes are behaving the same.
>
I've not got round to trying a build on my Solaris 2.6 box yet. I was
hoping that someone with something faster than a SPARC 2 would do
the biz and get the same results.
So we have at least two problems, some code that is tickling a gcc
optimiser bug (gcc 2.7.2.1 in my case) and an alignment bug in our
code that affects SPARC architecture.
I've half a mind to see if there is a later version of gcc that
does the optimisation correctly. (rpm format for Redhat 4.2)
The "create function" problem is a little harder for me to see
a way forward. ( my debugging skills are very few.)
Keith.
From | Date | Subject | |
---|---|---|---|
Next Message | Massimo Dal Zotto | 1998-08-31 20:51:21 | Re: [HACKERS] TPRINTF in trace.h |
Previous Message | korapat | 1998-08-31 18:40:57 | UNION opration NOT return all result set :) pls help |