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

From Tom Ivar Helbekkmo
Subject Re: [lockhart@alumni.caltech.edu: Third call for platform testing]
Date
Msg-id 86elv7kcl9.fsf@athene.i.eunet.no
Whole thread Raw
In response to Re: [lockhart@alumni.caltech.edu: Third call for platform testing]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [lockhart@alumni.caltech.edu: Third call for platform testing]  (Tom Lane <tgl@sss.pgh.pa.us>)
re: [lockhart@alumni.caltech.edu: Third call for platform testing]  (matthew green <mrg@eterna.com.au>)
NetBSD "Bad address" failure (was Re: Third call for platform testing)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> 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.


pgsql-hackers by date:

Previous
From: Adriaan Joubert
Date:
Subject: Re: ecpg long int problem on alpha + fix
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: ecpg long int problem on alpha + fix