Thread: Re: [HACKERS] Core dump in regression tests.
Thomas A. Szybist <szybist@boxhill.com> > > Hi, yes, I'm having trouble as well. Sorry to hear that but I don't feel quite so alone now ;-) > > I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot. > I've got an environment set up now to try a few things. Same thing here with -O2, I think some of the other pg_user, pg_view etc. problems all boil down to table creation as those are created as tables after bootstrapping and subsequently converted to views. > > Without -O2 it seem to be better. I see the same problem with > create function as you. Also many failures seem to the result > of some type not defined. Is that expected? Yes, there are many problems in the regression tests due to some type removal, I think, by Bruce. We're just waiting for the regression test "expected" results to catch up. > > Sorry to jump in so late here. > Better late than never <grin> Just out of interest, what platform are you running on? (S/Linux on an SUN IPX here) Keith.
In message <199808292119.WAA27374@mtcc.demon.co.uk>, Keith Parks writes: > > Thomas A. Szybist <szybist@boxhill.com> > > > > Hi, yes, I'm having trouble as well. > > Sorry to hear that but I don't feel quite so alone now ;-) Misery loves company :). > > > > > I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot. > > I've got an environment set up now to try a few things. > > Same thing here with -O2, I think some of the other pg_user, pg_view etc. > problems all boil down to table creation as those are created as > tables after bootstrapping and subsequently converted to views. > > > > > Without -O2 it seem to be better. I see the same problem with > > create function as you. Also many failures seem to the result > > of some type not defined. Is that expected? > > Yes, there are many problems in the regression tests due to some > type removal, I think, by Bruce. We're just waiting for the > regression test "expected" results to catch up. > > > > > Sorry to jump in so late here. > > > > Better late than never <grin> > > Just out of interest, what platform are you running on? > (S/Linux on an SUN IPX here) > > Keith. > This is on a Red Hat 4.1 (Yes 4.1) system. Thing is, it's a production system, and I haven't reason to upgrade. Kernel is 2.0.29 gcc 2.7.2.1. Sparc 20. I was toying with the idea of tossing Red Had 5.1 on a sparc classic, to see if glibc on S/Linux hoses anything. Tom Szybist szybist@boxhill.com
> In message <199808292119.WAA27374@mtcc.demon.co.uk>, Keith Parks writes: > > > > Thomas A. Szybist <szybist@boxhill.com> > > > > > > Hi, yes, I'm having trouble as well. > > > > Sorry to hear that but I don't feel quite so alone now ;-) > > Misery loves company :). > > > > > > > > > I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot. > > > I've got an environment set up now to try a few things. > > > > Same thing here with -O2, I think some of the other pg_user, pg_view etc. > > problems all boil down to table creation as those are created as > > tables after bootstrapping and subsequently converted to views. > > > > > > > > Without -O2 it seem to be better. I see the same problem with > > > create function as you. Also many failures seem to the result > > > of some type not defined. Is that expected? > > > > Yes, there are many problems in the regression tests due to some > > type removal, I think, by Bruce. We're just waiting for the > > regression test "expected" results to catch up. > > > > > > > > Sorry to jump in so late here. > > > > > > > Better late than never <grin> > > > > Just out of interest, what platform are you running on? > > (S/Linux on an SUN IPX here) > > > > Keith. > > > > This is on a Red Hat 4.1 (Yes 4.1) system. Thing is, it's a production > system, and I haven't reason to upgrade. > > Kernel is 2.0.29 gcc 2.7.2.1. Sparc 20. > > I was toying with the idea of tossing Red Had 5.1 on a sparc classic, > to see if glibc on S/Linux hoses anything. Again, if someone wants to conditionally compile the directories to find the offending file, I am sure we can get a fix for it. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
In message <199808300008.UAA15993@candle.pha.pa.us>, Bruce Momjian writes: > > In message <199808292119.WAA27374@mtcc.demon.co.uk>, Keith Parks writes: > > > > > > Thomas A. Szybist <szybist@boxhill.com> > > > > > > > > Hi, yes, I'm having trouble as well. > > > > > > Sorry to hear that but I don't feel quite so alone now ;-) > > > > Misery loves company :). > > > > > > > > > > > > > I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot. > > > > I've got an environment set up now to try a few things. > > > > > > Same thing here with -O2, I think some of the other pg_user, pg_view etc. > > > problems all boil down to table creation as those are created as > > > tables after bootstrapping and subsequently converted to views. > > > > > > > > > > > Without -O2 it seem to be better. I see the same problem with > > > > create function as you. Also many failures seem to the result > > > > of some type not defined. Is that expected? > > > > > > Yes, there are many problems in the regression tests due to some > > > type removal, I think, by Bruce. We're just waiting for the > > > regression test "expected" results to catch up. > > > > > > > > > > > Sorry to jump in so late here. > > > > > > > > > > Better late than never <grin> > > > > > > Just out of interest, what platform are you running on? > > > (S/Linux on an SUN IPX here) > > > > > > Keith. > > > > > > > This is on a Red Hat 4.1 (Yes 4.1) system. Thing is, it's a production > > system, and I haven't reason to upgrade. > > > > Kernel is 2.0.29 gcc 2.7.2.1. Sparc 20. > > > > I was toying with the idea of tossing Red Had 5.1 on a sparc classic, > > to see if glibc on S/Linux hoses anything. > > Again, if someone wants to conditionally compile the directories to find > the offending file, I am sure we can get a fix for it. > > -- > Bruce Momjian | 830 Blythe Avenue > maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 > + If your life is a hard drive, | (610) 353-9879(w) > + Christ can be your backup. | (610) 853-3000(h) > At first look it seems to be: backend/catalog/indexing.c. Maybe Keith can confirm? Thanks, Tom Szybist szybist@boxhill.com
I built and run the regression tests from a clean cvs tree this morning
(1998-08-30 20:00UTC). I have removed the oidint2, oidint4, and oidname
tests since the types no longer exist, and have updated alter_table to
remove mention of these types. I've committed these changes to the cvs
tree.
There are some failures (itemized below). The only failure I saw before
the big OID patch-fest was select_views.
So, the current status on my system (i686, Linux 2.0.30, RedHat 4.2, -O2
optimization enabled) is that all tests pass except the following:
- constraints .. failed
Core dump.
- create_index .. failed
Fails on all create index statements after the first one with the
message:
QUERY: CREATE INDEX onek_unique2 ON onek USING btree(unique2 int4_ops);
ERROR: DefineIndex: onek relation not found
but, this statement executes just fine after the regression tests have
completed and I connect in from another process:
regression=> CREATE INDEX onek_unique2 ON onek USING btree(unique2
int4_ops);
CREATE
Is it a cache problem somewhere??
sanity_check .. failed
> NOTICE: Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135)
> NOTICE: Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135)
These warnings weren't present before. Also sensitive to missing table
from constraints test failure.
select_having .. failed
Core dump.
select_views .. failed
Core dump. afaik this has been present for a month or two, and is a
failure on the last query in the test. EXPLAIN shows a valid result, so
the crash happens farther back.
run_ruletest .. failed
Apparently not critical; the test depends on the name of the dba being
"pgsql" and my system has a dba named "postgres". The test should be
fixed for v6.4.
- Tom
Thomas G. Lockhart wrote: > select_having .. failed > Core dump. > My bad. It is caused by a known bug having to do with GROUP BY. It ain't a good bug, but it has nothing to do with HAVING. For some reason the bug went away for a while, while I was building the test script. It must have, because that is how I created the expected file. :( A patch to the regression will be forthcoming.
Thomas, I have just run the regression test here with my indexing.c patch, and the only serious errors I see are the cases that have already been mentioned like the having core dump, and the postgres/pgsql rule difference. Do you still see other differences? Let me know. I am putting the two spaces after an elog message back in because I don't think we want to change that format for no good reason. I can see people expecting the string to look a certain way. > I built and run the regression tests from a clean cvs tree this morning > (1998-08-30 20:00UTC). I have removed the oidint2, oidint4, and oidname > tests since the types no longer exist, and have updated alter_table to > remove mention of these types. I've committed these changes to the cvs > tree. > > There are some failures (itemized below). The only failure I saw before > the big OID patch-fest was select_views. > > So, the current status on my system (i686, Linux 2.0.30, RedHat 4.2, -O2 > optimization enabled) is that all tests pass except the following: > > - constraints .. failed > Core dump. > > - create_index .. failed > Fails on all create index statements after the first one with the > message: > QUERY: CREATE INDEX onek_unique2 ON onek USING btree(unique2 int4_ops); > ERROR: DefineIndex: onek relation not found > but, this statement executes just fine after the regression tests have > completed and I connect in from another process: > regression=> CREATE INDEX onek_unique2 ON onek USING btree(unique2 > int4_ops); > CREATE > Is it a cache problem somewhere?? > > sanity_check .. failed > > NOTICE: Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135) > > NOTICE: Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135) > These warnings weren't present before. Also sensitive to missing table > from constraints test failure. > > select_having .. failed > Core dump. > > select_views .. failed > Core dump. afaik this has been present for a month or two, and is a > failure on the last query in the test. EXPLAIN shows a valid result, so > the crash happens farther back. > > run_ruletest .. failed > Apparently not critical; the test depends on the name of the dba being > "pgsql" and my system has a dba named "postgres". The test should be > fixed for v6.4. > > - Tom > > -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)