Lists: | pgsql-hackers |
---|
From: | "Larry Rosenman" <ler(at)lerctr(dot)org> |
---|---|
To: | "'pgsql-hackers list'" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Sanity Check? |
Date: | 2005-07-27 22:38:46 |
Message-ID: | E1DxuYx-0002Ml-Af@lerami.lerctr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(at)lerctr(dot)org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Larry Rosenman" <ler(at)lerctr(dot)org> |
Cc: | "'pgsql-hackers list'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sanity Check? |
Date: | 2005-07-27 22:52:08 |
Message-ID: | 12507.1122504728@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
"Larry Rosenman" <ler(at)lerctr(dot)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
From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sanity Check? |
Date: | 2005-07-27 23:12:24 |
Message-ID: | 20050727231224.GN1832@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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"
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sanity Check? |
Date: | 2005-07-28 00:12:10 |
Message-ID: | 13285.1122509530@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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