← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-proposed

« back to all changes in this revision

Viewing changes to src/backend/utils/adt/float.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-24 16:13:59 UTC
  • mfrom: (1.1.8)
  • Revision ID: package-import@ubuntu.com-20140724161359-uk325qfv03euxuuh
Tags: 9.3.5-0ubuntu0.14.04.1
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
    an issue with transaction information which causes VACUUM to eventually
    fail. These users should run the script provided in the release notes to
    determine if their installation is affected, and then take the remedy
    steps outlined there.
  - Various data integrity and other bug fixes.
  - Secure Unix-domain sockets of temporary postmasters started during make
    check.
    Any local user able to access the socket file could connect as the
    server's bootstrap superuser, then proceed to execute arbitrary code as
    the operating-system user running the test, as we previously noted in
    CVE-2014-0067. This change defends against that risk by placing the
    server's socket in a temporary, mode 0700 subdirectory of /tmp.
  - See release notes for details:
    http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
  upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/utils/adt/float.c
276
276
                        /*
277
277
                         * Some platforms return ERANGE for denormalized numbers (those
278
278
                         * that are not zero, but are too close to zero to have full
279
 
                         * precision).  We'd prefer not to throw error for that, so try to
 
279
                         * precision).  We'd prefer not to throw error for that, so try to
280
280
                         * detect whether it's a "real" out-of-range condition by checking
281
281
                         * to see if the result is zero or huge.
282
282
                         */
309
309
 
310
310
        /*
311
311
         * In some IRIX versions, strtod() recognizes only "inf", so if the input
312
 
         * is "infinity" we have to skip over "inity".  Also, it may return
 
312
         * is "infinity" we have to skip over "inity".  Also, it may return
313
313
         * positive infinity for "-inf".
314
314
         */
315
315
        if (isinf(val))
507
507
                        /*
508
508
                         * Some platforms return ERANGE for denormalized numbers (those
509
509
                         * that are not zero, but are too close to zero to have full
510
 
                         * precision).  We'd prefer not to throw error for that, so try to
 
510
                         * precision).  We'd prefer not to throw error for that, so try to
511
511
                         * detect whether it's a "real" out-of-range condition by checking
512
512
                         * to see if the result is zero or huge.
513
513
                         */
540
540
 
541
541
        /*
542
542
         * In some IRIX versions, strtod() recognizes only "inf", so if the input
543
 
         * is "infinity" we have to skip over "inity".  Also, it may return
 
543
         * is "infinity" we have to skip over "inity".  Also, it may return
544
544
         * positive infinity for "-inf".
545
545
         */
546
546
        if (isinf(val))
2118
2118
 * in that order.  Note that Y is the first argument to the aggregates!
2119
2119
 *
2120
2120
 * It might seem attractive to optimize this by having multiple accumulator
2121
 
 * functions that only calculate the sums actually needed.      But on most
 
2121
 * functions that only calculate the sums actually needed.  But on most
2122
2122
 * modern machines, a couple of extra floating-point multiplies will be
2123
2123
 * insignificant compared to the other per-tuple overhead, so I've chosen
2124
2124
 * to minimize code space instead.