Re: [lockhart@alumni.caltech.edu: Third call for platform testing] - Mailing list pgsql-hackers

(cc'd the -hackers mailing list)

Thanks for the reports Matthew. There is a single failure in the
NetBSD/sparc64 test due to a problem in the reltime test (or in starting
the reltime test). There is a different failure in your NetBSD/sparc
test, but since you are not confident about your installation we'll wait
to diagnose that (unless this rings a bell with someone).

Anyone have suggestions for Mathew?
                    - Thomas

> for postgresql-7.1RC2.tar.gz, here is my `make check' for NetBSD/sparc64:
>
>      [ ... ]
>      reltime              ... FAILED
>      [ ... ]
> test horology             ... FAILED
>      [ ... ]
>      inherit              ... FAILED
>      [ ... ]
> test misc                 ... FAILED
>      [ ... ]
> 
> =======================
>  4 of 76 tests failed.
> =======================
> 
> digging into the regression.diffs, i can see that:
>         - reltime failed because it just had:
> ! psql: Backend startup failed

Hmm. That one is a problem. Perhaps someone will have a suggestion?

>         - horology failed because of off-by-one errors somewhere:

Not a problem; I have an unintended dependency on daylight savings time,
which now causes this test to fail for everyone. The test itself should
be fixed for the release.

>         for several cases.  another failure here was due to:
> ! ERROR:  Relation 'reltime_tbl' does not exist
>         which i guess is caused by the first failure.

Yes, I think you are right.

>         - inherit fails because the ordering is invalid, eg:
> 
> -  a       | aaa
>    a       | aaaa
>    a       | aaaaa
>    a       | aaaaaa
>    a       | aaaaaaa
>    a       | aaaaaaaa
>    b       | bbb
>    b       | bbbb
>    b       | bbbbb
>    b       | bbbbbb
>    b       | bbbbbbb
> -  b       | bbbbbbbb
>    c       | ccc
> 
>         vs
> 
>    a       | aaaa
>    a       | aaaaa
>    a       | aaaaaa
>    a       | aaaaaaa
>    a       | aaaaaaaa
> +  a       | aaa
> +  b       | bbbbbbbb
>    b       | bbb
>    b       | bbbb
>    b       | bbbbb
>    b       | bbbbbb
>    b       | bbbbbbb
> 
>         there are dozens of these failures in the inherit test.
> 
>         - misc fails because of the reltime failure, i guess:
> 
> -  reltime_tbl
> 
> and:
> 
> ! (90 rows)
> --
> ! (89 rows)
> 
> i don't know anything about postgresql (i am merely testing at the
> suggestion of a friend) so i'm not very well equiped to debug these
> failures without some help.
> 
> and for NetBSD/sparc:
> 
>      [ ... ]
> test horology             ... FAILED
>      [ ... ]
>      create_index         ... FAILED
>      [ ... ]
> test sanity_check         ... FAILED
>      [ ... ]
> 
>         - horology fails for similar reasons as sparc64, but only 2
>         failures instead of about 15.
> 
>         - create_index failed because of some weird error that may
>         have more to do with the quick-n-dirty installation i have
>         on the SS20 i'm doing the test on:
> 
>   CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
>   + ERROR:  cannot read block 3 of hash_i4_index: Bad address
>   CREATE INDEX hash_name_index ON hash_name_heap USING hash (random name_ops);
>   + ERROR:  cannot read block 3 of hash_name_index: Bad address
>   CREATE INDEX hash_txt_index ON hash_txt_heap USING hash (random text_ops);
>   + ERROR:  cannot read block 3 of hash_txt_index: Bad address
>   CREATE INDEX hash_f8_index ON hash_f8_heap USING hash (random float8_ops);
>   + ERROR:  cannot read block 3 of hash_f8_index: Bad address
> 
>         - sanity_check fails because of the create_index failure:
> 
> -  hash_f8_heap        | t
> -  hash_i4_heap        | t
> -  hash_name_heap      | t
> -  hash_txt_heap       | t
> 
> ! (45 rows)
> vs
> ! (41 rows)
> 
> i will be reinstalling this SS20 with a full installation sometime in
> the next few days.  i will re-run the testsuite after this to see if
> that is causing any of the lossage.  none of the sparc64 lossage should
> be related, and that was run on an Ultra1/140 FWIW.  both of these were
> run under NetBSD 1.5S (-current from a few weeks ago.)
> 
> .mrg.