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

Поиск
Список
Период
Сортировка
От Tom Ivar Helbekkmo
Тема Re: [lockhart@alumni.caltech.edu: Third call for platform testing]
Дата
Msg-id 86elv7kcl9.fsf@athene.i.eunet.no
обсуждение исходный текст
Ответ на 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]  (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>)
Список 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 по дате отправления:

Предыдущее
От: Adriaan Joubert
Дата:
Сообщение: Re: ecpg long int problem on alpha + fix
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: ecpg long int problem on alpha + fix