On 2017-10-24 10:09:09 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > There's no comparable overflow handling to the above integer > > intrinsics. But I think we can still do a lot better. Two very different > > ways: > > > 1) Just give up on detecting overflows for floats. Generating inf in > > these cases actually seems entirely reasonable. We already don't > > detect them in a bunch of cases anyway. I can't quite parse the > > standard's language around this. > > There's an ancient saying that code can be arbitrarily fast if it > doesn't have to get the right answer. I think this proposal falls > in that category.
Does it? In plenty of cases getting infinity rather than an error is just about as useful. This was argued by a certain Tom Lane a few years back ;) http://archives.postgresql.org/message-id/19208.1167246902%40sss.pgh.pa.us > > 2) Use platform specific float exception handling where available. We > > could at backend start, and in FloatExceptionHandler(), us > > feenableexcept() (windows has similar) to trigger SIGFPE on float > > overflow. > > SIGFPE isn't going to be easy to recover from, nor portable. Hm? A trivial hack implementing the above survives the regression test, with the exception of one output change because some functions currently do *not* check for overflow. What's the issue you're concerned about? The portability indeed is a problem. > I think what you actually want to do is *disable* SIGFPE (see > feholdexcept), and then have individual functions use feclearexcept > and fetestexcept. These functions were standardized by C99 so > they should be pretty widely available ... of course, whether they > actually are widely portable remains to be seen. Whether they're > faster than what we're doing now also remains to be seen. I tested it, and they're fairly slow on at least gcc-7 + glibc 2.24. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
