From: | Tom Ivar Helbekkmo <tih(at)kpnQwest(dot)no> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | lockhart(at)fourpalms(dot)org, matthew green <mrg(at)eterna(dot)com(dot)au>, ivan <ivan(at)420(dot)am>, Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [lockhart@alumni.caltech.edu: Third call for platform testing] |
Date: | 2001-04-05 07:52:34 |
Message-ID: | 86elv7kcl9.fsf@athene.i.eunet.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2001-04-05 08:01:53 | AW: ecpg long int problem on alpha + fix |
Previous Message | Adriaan Joubert | 2001-04-05 06:13:49 | Re: ecpg long int problem on alpha + fix |