<ragge@ludd.luth.se> writes:

> This is correct behavoiur, NaN on vax is considered an
> illegal value to deal with.  Actually there is no NaN on vax,
> so it is setup to give a trap instead.

So, PostgreSQL should, where it parses a "NaN" string as data input,
generate an error itself (illegal float, not implemented, whatever),
to keep strtod() from crashing the database backup.  OK.

But what about that polyd thing?  The only change I've made to libm
was to comment out that single instruction from the assembly source to
atan2(), and, while atan2() now definitely doesn't work, code that
uses it no longer crashes on an illegal instruction.  However, I'm
afraid I'm out of my depth when it comes to finding out where in the
emulation code it's at when it happens...

Can you suggest something I can do to test further?

-tih
-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.