On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
> Andres Freund <andres@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
