Re: [lockhart@alumni.caltech.edu: Third call for platform testing]

(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.