Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Core dump in regression tests.

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Thomas A(dot) Szybist" <szybist(at)boxhill(dot)com>, emkxp01(at)mtcc(dot)demon(dot)co(dot)uk, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Core dump in regression tests.
Date: 1998-08-30 20:31:31
Message-ID: 35E9B6A3.9526062F@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-08-30 21:11:21
Subject: Re: [HACKERS] Open 6.4 items
Previous:From: Thomas A. SzybistDate: 1998-08-30 19:59:35
Subject: Re: [HACKERS] Core dump in regression tests.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group