re: NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)

2001-04-16 Thread matthew green
yes, this is a bug in netbsd-current that was introduced with about 5 month ago with the new unified buffer cache system. it has been fixed. thanks. From: Chuck Silvers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: CVS commit: syssrc Date: Mon, 16 Apr 2001 17:37:44 +0300 (EEST)

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

2001-04-07 Thread matthew green
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

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

2001-04-07 Thread matthew green
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

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

2001-04-07 Thread matthew green
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

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

2001-04-07 Thread matthew green
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