Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
matthew green <[EMAIL PROTECTED]> writes: > i also believe the `Bad address' errors were caused when the test > was run in an NFS mounted directory. You may have something, there. My test run on the VAX was over NFS. I set up NetBSD on a VAX specifically to test PostgreSQL 7.1, but I didn't have any disk available that it could use, so I went for NFS. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
> >> 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 > > "Bad address"? That seems pretty bizarre. This is obviously something that shows up on _some_ NetBSD platforms. The above was on sparc64, but that same problem is the only one I see that Bad address message was actually from sparc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
matthew green <[EMAIL PROTECTED]> writes: > digging into the regression.diffs, i can see that: > - reltime failed because it just had: > ! psql: Backend startup failed >The postmaster log file should have more info, but a first thought is >that you ran up against process or swap-space limitations. The parallel >check has fifty-odd processes going at its peak, which is more than the >default per-user process limit on many Unixen. > hmm, maxproc=80 on this system currently and i wasn't really doing anything > else. it has 256MB ram and 280MB swap (unused). exactly what am i looking > for in the postmaster.log file? it is 65kb long... Look for messages about "fork failed". They should give a kernel error message too. after running `unlimit' (tcsh) before `make check', the only failures i have are the horology (expected) and the inherit sorted failures, on NetBSD/sparc64. i also believe the `Bad address' errors were caused when the test was run in an NFS mounted directory. .mrg. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
>> digging into the regression.diffs, i can see that: >> - reltime failed because it just had: >> ! psql: Backend startup failed The postmaster log file should have more info, but a first thought is that you ran up against process or swap-space limitations. The parallel check has fifty-odd processes going at its peak, which is more than the default per-user process limit on many Unixen. hmm, maxproc=80 on this system currently and i wasn't really doing anything else. it has 256MB ram and 280MB swap (unused). exactly what am i looking for in the postmaster.log file? it is 65kb long... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
>> 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. Please let us know. actually, i had a classic i could test with -- all except horology passed, so if there were two expected failures there, all is fine on NetBSD/sparc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
> after running `unlimit' (tcsh) before `make check', the only failures i have > are the horology (expected) and the inherit sorted failures, on NetBSD/sparc64. I'll mark both NetBSD/sparc as supported, for both 32 and 64-bit builds. Thanks! - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: > 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 >> >> "Bad address"? That seems pretty bizarre. > This is obviously something that shows up on _some_ NetBSD platforms. If it's reproducible on more than one box then we should look into it. Am I right to guess that "Bad address" means a bogus pointer handed to a kernel call? If so, it'll probably take some digging with gdb to find out the cause. I'd be happy to do the digging if anyone can give me an account reachable via telnet or ssh on one of these machines. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
matthew green <[EMAIL PROTECTED]> writes: > digging into the regression.diffs, i can see that: > - reltime failed because it just had: > ! psql: Backend startup failed >The postmaster log file should have more info, but a first thought is >that you ran up against process or swap-space limitations. The parallel >check has fifty-odd processes going at its peak, which is more than the >default per-user process limit on many Unixen. > hmm, maxproc=80 on this system currently and i wasn't really doing anything > else. it has 256MB ram and 280MB swap (unused). exactly what am i looking > for in the postmaster.log file? it is 65kb long... Look for messages about "fork failed". They should give a kernel error message too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
Tom Lane <[EMAIL PROTECTED]> writes: > >> 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 > > "Bad address"? That seems pretty bizarre. This is obviously something that shows up on _some_ NetBSD platforms. The above was on sparc64, but that same problem is the only one I see in the regression testing on NetBSD/vax that isn't just different floating point (the VAX doesn't have IEEE), different ordering of (unordered) collections or different wording of strerror() output. NetBSD/i386 doesn't have the "Bad address" problem. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
Thomas Lockhart <[EMAIL PROTECTED]> writes: > Anyone have suggestions for Mathew? >> for postgresql-7.1RC2.tar.gz, here is my `make check' for NetBSD/sparc64: >> digging into the regression.diffs, i can see that: >> - reltime failed because it just had: >> ! psql: Backend startup failed The postmaster log file should have more info, but a first thought is that you ran up against process or swap-space limitations. The parallel check has fifty-odd processes going at its peak, which is more than the default per-user process limit on many Unixen. >> - inherit fails because the ordering is invalid, eg: Ordering issues are not really bugs (cf documentation about interpreting regression results), although it'd be interesting to know if these diffs still occur after you resolve the other failures. >> - 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 "Bad address"? That seems pretty bizarre. >> 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. Please let us know. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [lockhart@alumni.caltech.edu: [HACKERS] 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 | >a | a >a | aa >a | aaa >a | >b | bbb >b | >b | b >b | bb >b | bbb > - b | >c | ccc > > vs > >a | >a | a >a | aa >a | aaa >a | > + a | aaa > + b | >b | bbb >b | >b | b >b | bb >b | bbb > > 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. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
