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

Re: Sanity Check?

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-hackers by date

Next:From: Kevin McArthurDate: 2005-07-27 22:58:13
Subject: Re: RESULT_OID Bug
Previous:From: Josh BerkusDate: 2005-07-27 22:41:35
Subject: Re: Integrated autovacuum

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