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 ;)

> > 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.


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to