Re: PostgreSQL for VAX on NetBSD/OpenBSD
От | Tom Lane |
---|---|
Тема | Re: PostgreSQL for VAX on NetBSD/OpenBSD |
Дата | |
Msg-id | 18204.1440080975@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL for VAX on NetBSD/OpenBSD (Greg Stark <stark@mit.edu>) |
Ответы |
Re: PostgreSQL for VAX on NetBSD/OpenBSD
Re: PostgreSQL for VAX on NetBSD/OpenBSD |
Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes: > So I've been playing with this a bit. I have simh running on my home > server as a Vax 3900 with NetBSD 6.1.5. My home server was mainly > intended to be a SAN and its cpu is woefully underpowered so the > resulting VAX is actually very very slow. So slow I wonder if there's > a bug in the emulator but anyways. Fun fun! > There are some planner tests that fail with floating point exceptions > -- that's probably a bug on our part. And I've seen at least one > server crash (maybe two) apparently caused by one as well which I > don't believe is expected. That seems worth poking into. > 3) The tests take so long to run that autovacuum kicks in and the > tests start producing rows in inconsistent orderings. I assume that's > a problem we've run into on the CLOBBER_CACHE animals as well? I'd tentatively bet that it's more like planner behavioral differences due to different floating-point roundoff. > 4) One of the tablesample tests seems to freeze indefinitely. I > haven't looked into why yet. That might indeed indicate that the > spinlock code isn't working? The tablesample tests seem like a not-very-likely first place for such a thing to manifest. What I'm thinking is that there are places in there where we loop till we get an expected result. Offhand I thought they were all integer math; but if one was float and the VAX code wasn't doing what was expected, maybe we could blame this on float discrepancies as well. regards, tom lane
В списке pgsql-hackers по дате отправления: