Re: [HACKERS] Core dump in regression tests.
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Core dump in regression tests. |
Дата | |
Msg-id | 35E9B6A3.9526062F@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Core dump in regression tests. (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Core dump in regression tests.
|
Список | 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
В списке pgsql-hackers по дате отправления: