Обсуждение: 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