Thread: Sanity Check?
SCO is seeing the following failure without -O, but no failure with -O: The sanity_check diffs show: *** ./expected/sanity_check.out Wed Jul 27 17:58:12 2005 --- ./results/sanity_check.out Wed Jul 27 18:09:41 2005 *************** *** 17,22 **** --- 17,24 ---- circle_tbl | t fast_emp4000 | t func_index_heap | t + gcircle_tbl | t + gpolygon_tbl | t hash_f8_heap | t hash_i4_heap | t hash_name_heap | t *************** *** 67,73 **** shighway | t tenk1 | t tenk2 | t ! (57 rows) -- -- another sanity check: every system catalog that has OIDs should have --- 69,75 ---- shighway | t tenk1 | t tenk2 | t ! (59 rows) -- -- another sanity check: every system catalog that has OIDs should have Any ideas? I'm **NOT** seeing this on my box, but. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
"Larry Rosenman" <ler@lerctr.org> writes: > SCO is seeing the following failure without -O, but no failure with -O: > *** ./expected/sanity_check.out Wed Jul 27 17:58:12 2005 > --- ./results/sanity_check.out Wed Jul 27 18:09:41 2005 > *************** > *** 17,22 **** > --- 17,24 ---- > circle_tbl | t > fast_emp4000 | t > func_index_heap | t > + gcircle_tbl | t > + gpolygon_tbl | t > hash_f8_heap | t > hash_i4_heap | t > hash_name_heap | t Hmm. This looks like a race condition in the test to me. gcircle_tbl and gpolygon_tbl are temp tables created during the create_index test. They do have indexes, so if the backend that ran create_index hadn't managed to delete 'em yet, it'd make sense that they show up in sanity_check's query. And in the parallel regression schedule, create_index does run directly before sanity_check. Those temp tables are recently introduced, I believe, so the fact that this hasn't been reported before doesn't mean it can't happen elsewhere than SCO machines. It's pretty surprising though that sanity_check manages to execute a complete database-wide VACUUM before the create_index backend has managed to drop its couple of temp tables. So there may be something wrong with this explanation; or there might be something weird about the kernel scheduling policy on their machine. regards, tom lane
Why does the sanity check test start with a VACUUM? Why not a VACUUM FULL? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) "Los románticos son seres que mueren de deseos de vida"
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Why does the sanity check test start with a VACUUM? Why not a VACUUM > FULL? The test predates the existence of VACUUM FULL ;-); so that's what it did originally. I think I deliberately left it as-is during the 7.2 devel cycle, so that the new lazy-vacuum code would get exercised. I don't see any strong reason to change it now ... regards, tom lane