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

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.

In response to

Responses

Browse pgsql-hackers by date

  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