Обсуждение: BUG #14913: Test for aggregates fails

The following bug has been logged on the website:

Bug reference:      14913
Logged by:          Jens With
Email address:      jens.with@t-online.de
PostgreSQL version: 10.1
Operating system:   OEL 4.9
Description:

./configure --enable-static --enable-shared --with-includes=$IMPROOT/include
--with-libraries=$IMPLIB --exec_prefix=$IMPROOT --bindir=$IMPBIN
--libdir=$IMPLIB --prefix=$IMPROOT --with-pgport=$port

parallel group (20 tests):  select_into select_distinct select_distinct_on
select_implicit select_having subselect case aggregates transactions random
portals arrays btree_index union update join namespace delete hash_index
prepared_xacts
     select_into              ... ok
     select_distinct          ... ok
     select_distinct_on       ... ok
     select_implicit          ... ok
     select_having            ... ok
     subselect                ... ok
     union                    ... ok
     case                     ... ok
     join                     ... ok
     aggregates               ... FAILED
     transactions             ... ok
     random                   ... ok
     portals                  ... ok
     arrays                   ... ok
     btree_index              ... ok
     hash_index               ... ok
     update                   ... ok
     namespace                ... ok
     prepared_xacts           ... ok
     delete                   ... ok

***
/imphome/imppg/.install/impmake/postgresql/postgresql-10.1/src/test/regress/expected/aggregates.out    Tue
Nov  7 01:46:52 2017
---
/imphome/imppg/.install/impmake/postgresql/postgresql-10.1/src/test/regress/results/aggregates.out    Thu
Nov 16 22:26:48 2017
***************
*** 1575,1583 ****
  
  select percentile_disc(array[0,0.1,0.25,0.5,0.75,0.9,1]) within group
(order by thousand)
  from tenk1;
!       percentile_disc       
! ----------------------------
!  {0,99,249,499,749,899,999}
  (1 row)
  
  select percentile_cont(array[0,0.25,0.5,0.75,1]) within group (order by
thousand)
--- 1575,1583 ----
  
  select percentile_disc(array[0,0.1,0.25,0.5,0.75,0.9,1]) within group
(order by thousand)
  from tenk1;
!        percentile_disc       
! -----------------------------
!  {0,100,249,499,749,900,999}
  (1 row)
  
  select percentile_cont(array[0,0.25,0.5,0.75,1]) within group (order by
thousand)

======================================================================

jens.with@t-online.de writes:
> ***************
> *** 1575,1583 **** 
>   select percentile_disc(array[0,0.1,0.25,0.5,0.75,0.9,1]) within group
> (order by thousand)
>   from tenk1;
> !       percentile_disc       
> ! ----------------------------
> !  {0,99,249,499,749,899,999}
>   (1 row) 
>   select percentile_cont(array[0,0.25,0.5,0.75,1]) within group (order by
> thousand)
> --- 1575,1583 ---- 
>   select percentile_disc(array[0,0.1,0.25,0.5,0.75,0.9,1]) within group
> (order by thousand)
>   from tenk1;
> !        percentile_disc       
> ! -----------------------------
> !  {0,100,249,499,749,900,999}
>   (1 row) 
>   select percentile_cont(array[0,0.25,0.5,0.75,1]) within group (order by
> thousand)

Odd.  Given the lack of similar reports, it must be something rather
platform-specific.  I'm afraid you're going to have to do some of your
own sleuthing.  Just looking at the code, it seems like this might
be explainable as a roundoff-error problem, if somehow (double) 0.1
times 10000 gives a smidge more than 1000.  But I wouldn't really
expect any modern platform to get that wrong.  Unless maybe you're
using -ffast-math, or some other accuracy-sacrificing compiler option?

BTW, that test has been there since 9.4.  Which earlier versions of PG
have you successfully tested on the same platform?
        regards, tom lane