pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedmaster make check fails on Solaris 10
46+ messages / 6 participants
[nested] [flat]
Commits from this thread:
2018-01-18 2082b3745a 456cab29df 31635bc1d1 5dcbdcbdda Extend configure's __int128 test to check for a known gcc bug.
* master make check fails on Solaris 10
@ 2018-01-11 17:21 Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 2 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-11 17:21 UTC (permalink / raw)
To: pgsql-hackers
Hello, hackers! I got a permanent failure of master (commit
ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Regression output and diffs are attached.
I used the following commands:
./configure CC="ccache gcc" CFLAGS="-m64 -I/opt/csw/include"
LDFLAGS="-L/opt/csw/lib/sparcv9 -L/usr/local/lib/64" --enable-cassert
--enable-debug --enable-nls --with-perl --with-tcl --with-python
--with-gssapi --with-openssl --with-ldap --with-libxml --with-libxslt
gmake > make_results.txt
gmake check
About the system: SunOS, Release 5.10, KernelID Generic_141444-09.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
regression.diffs (text/x-diff, 30.5K) download
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/random.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/random.out Thu Jan 11 20:10:29 2018
***************
*** 46,52 ****
SELECT AVG(random) FROM RANDOM_TBL
HAVING AVG(random) NOT BETWEEN 80 AND 120;
! avg
! -----
! (0 rows)
--- 46,53 ----
SELECT AVG(random) FROM RANDOM_TBL
HAVING AVG(random) NOT BETWEEN 80 AND 120;
! avg
! ----------------------
! 13835058055282163712
! (1 row)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/groupingsets.out Thu Jan 11 19:37:50 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/groupingsets.out Thu Jan 11 20:11:18 2018
***************
*** 143,156 ****
-- nesting with window functions
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by rollup (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | | 12 | 36
(6 rows)
-- nesting with grouping sets
--- 143,156 ----
-- nesting with window functions
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by rollup (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79506866991776385725089447936
! 1 | | 10 | 159013733983552771450178895872
! 2 | 2 | 2 | 238520600975329157175268343808
! 2 | | 2 | 318027467967105542900357791744
! | | 12 | 397534334958881928625447239680
(6 rows)
-- nesting with grouping sets
***************
*** 544,559 ****
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | 1 | 8 | 32
! | 2 | 4 | 36
! | | 12 | 48
(8 rows)
select a, b, sum(c) from (values (1,1,10),(1,1,11),(1,2,12),(1,2,13),(1,3,14),(2,3,15),(3,3,16),(3,4,17),(4,1,18),(4,1,19)) v(a,b,c) group by rollup (a,b);
--- 544,559 ----
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79523549341672933105512480768
! 1 | | 10 | 159047098683345866211024961536
! 2 | 2 | 2 | 238570648025018799316537442304
! 2 | | 2 | 318094197366691732422049923072
! | 1 | 8 | 397617746708364665527562403840
! | 2 | 4 | 477141296050037598633074884608
! | | 12 | 556664845391710531738587365376
(8 rows)
select a, b, sum(c) from (values (1,1,10),(1,1,11),(1,2,12),(1,2,13),(1,3,14),(2,3,15),(3,3,16),(3,4,17),(4,1,18),(4,1,19)) v(a,b,c) group by rollup (a,b);
***************
*** 1219,1234 ****
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | 1 | 8 | 32
! | 2 | 4 | 36
! | | 12 | 48
(8 rows)
explain (costs off)
--- 1219,1234 ----
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79525973686566076309624061952
! 1 | | 10 | 159051947373132152619248123904
! 2 | 2 | 2 | 238577921059698228928872185856
! 2 | | 2 | 318103894746264305238496247808
! | 1 | 8 | 397629868432830381548120309760
! | 2 | 4 | 477155842119396457857744371712
! | | 12 | 556681815805962534167368433664
(8 rows)
explain (costs off)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/tsrf.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/tsrf.out Thu Jan 11 20:11:37 2018
***************
*** 251,259 ****
SELECT SUM(count(*)) OVER(PARTITION BY generate_series(1,3) ORDER BY generate_series(1,3)), generate_series(1,3) g FROM few GROUP BY g;
sum | g
-----+---
! 3 | 1
! 3 | 2
! 3 | 3
(3 rows)
-- sorting + grouping
--- 251,259 ----
SELECT SUM(count(*)) OVER(PARTITION BY generate_series(1,3) ORDER BY generate_series(1,3)), generate_series(1,3) g FROM few GROUP BY g;
sum | g
-----+---
! 0 | 1
! 0 | 2
! 0 | 3
(3 rows)
-- sorting + grouping
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/select_parallel.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/select_parallel.out Thu Jan 11 20:12:08 2018
***************
*** 722,730 ****
(5 rows)
select avg(unique1::int8) from tenk1;
! avg
! -----------------------
! 4999.5000000000000000
(1 row)
-- gather merge test with a LIMIT
--- 722,730 ----
(5 rows)
select avg(unique1::int8) from tenk1;
! avg
! -------------------------------
! 79303822316963263408196849290
(1 row)
-- gather merge test with a LIMIT
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/window.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/window.out Thu Jan 11 20:12:21 2018
***************
*** 51,78 ****
-- with GROUP BY
SELECT four, ten, SUM(SUM(four)) OVER (PARTITION BY four), AVG(ten) FROM tenk1
GROUP BY four, ten ORDER BY four, ten;
! four | ten | sum | avg
! ------+-----+------+------------------------
! 0 | 0 | 0 | 0.00000000000000000000
! 0 | 2 | 0 | 2.0000000000000000
! 0 | 4 | 0 | 4.0000000000000000
! 0 | 6 | 0 | 6.0000000000000000
! 0 | 8 | 0 | 8.0000000000000000
! 1 | 1 | 2500 | 1.00000000000000000000
! 1 | 3 | 2500 | 3.0000000000000000
! 1 | 5 | 2500 | 5.0000000000000000
! 1 | 7 | 2500 | 7.0000000000000000
! 1 | 9 | 2500 | 9.0000000000000000
! 2 | 0 | 5000 | 0.00000000000000000000
! 2 | 2 | 5000 | 2.0000000000000000
! 2 | 4 | 5000 | 4.0000000000000000
! 2 | 6 | 5000 | 6.0000000000000000
! 2 | 8 | 5000 | 8.0000000000000000
! 3 | 1 | 7500 | 1.00000000000000000000
! 3 | 3 | 7500 | 3.0000000000000000
! 3 | 5 | 7500 | 5.0000000000000000
! 3 | 7 | 7500 | 7.0000000000000000
! 3 | 9 | 7500 | 9.0000000000000000
(20 rows)
SELECT depname, empno, salary, sum(salary) OVER w FROM empsalary WINDOW w AS (PARTITION BY depname);
--- 51,78 ----
-- with GROUP BY
SELECT four, ten, SUM(SUM(four)) OVER (PARTITION BY four), AVG(ten) FROM tenk1
GROUP BY four, ten ORDER BY four, ten;
! four | ten | sum | avg
! ------+-----+--------------------------------+------------------------
! 0 | 0 | 318029156213123168798521688064 | 0.00000000000000000000
! 0 | 2 | 318029156213123168798521688064 | 2.0000000000000000
! 0 | 4 | 318029156213123168798521688064 | 4.0000000000000000
! 0 | 6 | 318029156213123168798521688064 | 6.0000000000000000
! 0 | 8 | 318029156213123168798521688064 | 8.0000000000000000
! 1 | 1 | 318029156213123168798521688064 | 1.00000000000000000000
! 1 | 3 | 318029156213123168798521688064 | 3.0000000000000000
! 1 | 5 | 318029156213123168798521688064 | 5.0000000000000000
! 1 | 7 | 318029156213123168798521688064 | 7.0000000000000000
! 1 | 9 | 318029156213123168798521688064 | 9.0000000000000000
! 2 | 0 | 318029156213123168798521688064 | 0.00000000000000000000
! 2 | 2 | 318029156213123168798521688064 | 2.0000000000000000
! 2 | 4 | 318029156213123168798521688064 | 4.0000000000000000
! 2 | 6 | 318029156213123168798521688064 | 6.0000000000000000
! 2 | 8 | 318029156213123168798521688064 | 8.0000000000000000
! 3 | 1 | 318029156213123168798521688064 | 1.00000000000000000000
! 3 | 3 | 318029156213123168798521688064 | 3.0000000000000000
! 3 | 5 | 318029156213123168798521688064 | 5.0000000000000000
! 3 | 7 | 318029156213123168798521688064 | 7.0000000000000000
! 3 | 9 | 318029156213123168798521688064 | 9.0000000000000000
(20 rows)
SELECT depname, empno, salary, sum(salary) OVER w FROM empsalary WINDOW w AS (PARTITION BY depname);
***************
*** 411,428 ****
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER (PARTITION BY two ORDER BY ten) AS wsum
FROM tenk1 GROUP BY ten, two;
! ten | two | gsum | wsum
! -----+-----+-------+--------
! 0 | 0 | 45000 | 45000
! 2 | 0 | 47000 | 92000
! 4 | 0 | 49000 | 141000
! 6 | 0 | 51000 | 192000
! 8 | 0 | 53000 | 245000
! 1 | 1 | 46000 | 46000
! 3 | 1 | 48000 | 94000
! 5 | 1 | 50000 | 144000
! 7 | 1 | 52000 | 196000
! 9 | 1 | 54000 | 250000
(10 rows)
SELECT count(*) OVER (PARTITION BY four), four FROM (SELECT * FROM tenk1 WHERE two = 1)s WHERE unique2 < 10;
--- 411,428 ----
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER (PARTITION BY two ORDER BY ten) AS wsum
FROM tenk1 GROUP BY ten, two;
! ten | two | gsum | wsum
! -----+-----+-------+--------------------------------
! 0 | 0 | 45000 | 0
! 2 | 0 | 47000 | 79507275771625059128753258496
! 4 | 0 | 49000 | 159014551543250118257506516992
! 6 | 0 | 51000 | 238521827314875177386259775488
! 8 | 0 | 53000 | 318029103086500236515013033984
! 1 | 1 | 46000 | 0
! 3 | 1 | 48000 | 79507275771625059128753258496
! 5 | 1 | 50000 | 159014551543250118257506516992
! 7 | 1 | 52000 | 238521827314875177386259775488
! 9 | 1 | 54000 | 318029103086500236515013033984
(10 rows)
SELECT count(*) OVER (PARTITION BY four), four FROM (SELECT * FROM tenk1 WHERE two = 1)s WHERE unique2 < 10;
***************
*** 483,500 ****
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER win AS wsum
FROM tenk1 GROUP BY ten, two WINDOW win AS (PARTITION BY two ORDER BY ten);
! ten | two | gsum | wsum
! -----+-----+-------+--------
! 0 | 0 | 45000 | 45000
! 2 | 0 | 47000 | 92000
! 4 | 0 | 49000 | 141000
! 6 | 0 | 51000 | 192000
! 8 | 0 | 53000 | 245000
! 1 | 1 | 46000 | 46000
! 3 | 1 | 48000 | 94000
! 5 | 1 | 50000 | 144000
! 7 | 1 | 52000 | 196000
! 9 | 1 | 54000 | 250000
(10 rows)
-- more than one window with GROUP BY
--- 483,500 ----
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER win AS wsum
FROM tenk1 GROUP BY ten, two WINDOW win AS (PARTITION BY two ORDER BY ten);
! ten | two | gsum | wsum
! -----+-----+-------+--------------------------------
! 0 | 0 | 45000 | 0
! 2 | 0 | 47000 | 79507275771625059128753258496
! 4 | 0 | 49000 | 159014551543250118257506516992
! 6 | 0 | 51000 | 238521827314875177386259775488
! 8 | 0 | 53000 | 318029103086500236515013033984
! 1 | 1 | 46000 | 0
! 3 | 1 | 48000 | 79507275771625059128753258496
! 5 | 1 | 50000 | 159014551543250118257506516992
! 7 | 1 | 52000 | 238521827314875177386259775488
! 9 | 1 | 54000 | 318029103086500236515013033984
(10 rows)
-- more than one window with GROUP BY
***************
*** 502,512 ****
row_number() OVER (ORDER BY depname),
sum(sum(salary)) OVER (ORDER BY depname DESC)
FROM empsalary GROUP BY depname;
! sum | row_number | sum
! -------+------------+-------
! 14600 | 3 | 14600
! 7400 | 2 | 22000
! 25100 | 1 | 47100
(3 rows)
-- identical windows with different names
--- 502,512 ----
row_number() OVER (ORDER BY depname),
sum(sum(salary)) OVER (ORDER BY depname DESC)
FROM empsalary GROUP BY depname;
! sum | row_number | sum
! -------+------------+--------------------------------
! 14600 | 3 | 0
! 7400 | 2 | 79507275771625059128753258496
! 25100 | 1 | 159014551543250118257506516992
(3 rows)
-- identical windows with different names
***************
*** 1027,1037 ****
) FILTER (WHERE depname <> 'sales') OVER (ORDER BY depname DESC) AS "filtered_sum",
depname
FROM empsalary GROUP BY depname;
! sum | row_number | filtered_sum | depname
! -------+------------+--------------+-----------
! 14600 | 3 | | sales
! 7400 | 2 | 3500 | personnel
! 25100 | 1 | 22600 | develop
(3 rows)
-- Test pushdown of quals into a subquery containing window functions
--- 1027,1037 ----
) FILTER (WHERE depname <> 'sales') OVER (ORDER BY depname DESC) AS "filtered_sum",
depname
FROM empsalary GROUP BY depname;
! sum | row_number | filtered_sum | depname
! -------+------------+-------------------------------+-----------
! 14600 | 3 | | sales
! 7400 | 2 | 0 | personnel
! 25100 | 1 | 79507275771625059128753258496 | develop
(3 rows)
-- Test pushdown of quals into a subquery containing window functions
***************
*** 1341,1352 ****
-- test inverse transition functions handle NULLs properly
SELECT i,AVG(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | avg
! ---+--------------------
! 1 | 1.5000000000000000
! 2 | 2.0000000000000000
! 3 |
! 4 |
(4 rows)
SELECT i,AVG(v::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1341,1352 ----
-- test inverse transition functions handle NULLs properly
SELECT i,AVG(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | avg
! ---+-------------------------------
! 1 | 39753637885812529564376629248
! 2 | 0.00000000000000000000
! 3 |
! 4 |
(4 rows)
SELECT i,AVG(v::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1411,1422 ****
SELECT i,SUM(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | sum
! ---+-----
! 1 | 3
! 2 | 2
! 3 |
! 4 |
(4 rows)
SELECT i,SUM(v::money) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1411,1422 ----
SELECT i,SUM(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | sum
! ---+-------------------------------
! 1 | 79507275771625059128753258496
! 2 | 0
! 3 |
! 4 |
(4 rows)
SELECT i,SUM(v::money) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1491,1514 ****
SELECT VAR_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! -----------------------
! 21704.000000000000
! 13868.750000000000
! 11266.666666666667
! 4225.0000000000000000
! 0
(5 rows)
SELECT VAR_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! -----------------------
! 21704.000000000000
! 13868.750000000000
! 11266.666666666667
! 4225.0000000000000000
! 0
(5 rows)
SELECT VAR_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1491,1514 ----
SELECT VAR_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! ---------
! 0
! 0
! 0
! 0
! 0
(5 rows)
SELECT VAR_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! ---------
! 0
! 0
! 0
! 0
! 0
(5 rows)
SELECT VAR_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1535,1558 ****
SELECT VAR_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VAR_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VAR_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1535,1558 ----
SELECT VAR_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VAR_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VAR_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1579,1602 ****
SELECT VARIANCE(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VARIANCE(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VARIANCE(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1579,1602 ----
SELECT VARIANCE(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VARIANCE(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VARIANCE(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1624,1649 ****
SELECT STDDEV_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ---------------------
! 147.322774885623
! 147.322774885623
! 117.765657133139
! 106.144555520604
! 65.0000000000000000
! 0
(6 rows)
SELECT STDDEV_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ---------------------
! 147.322774885623
! 147.322774885623
! 117.765657133139
! 106.144555520604
! 65.0000000000000000
! 0
(6 rows)
SELECT STDDEV_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1624,1649 ----
SELECT STDDEV_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ------------
! 0
! 0
! 0
! 0
! 0
! 0
(6 rows)
SELECT STDDEV_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ------------
! 0
! 0
! 0
! 0
! 0
! 0
(6 rows)
SELECT STDDEV_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1672,1697 ****
SELECT STDDEV_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1672,1697 ----
SELECT STDDEV_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! -------------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! -------------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1720,1745 ****
SELECT STDDEV(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1720,1745 ----
SELECT STDDEV(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! --------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! --------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/with.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/with.out Thu Jan 11 20:12:39 2018
***************
*** 285,291 ****
SELECT count(*) FROM q1 WHERE y > (SELECT sum(y)/100 FROM q1 qsub);
count
-------
! 50
(1 row)
-- via a VIEW
--- 285,291 ----
SELECT count(*) FROM q1 WHERE y > (SELECT sum(y)/100 FROM q1 qsub);
count
-------
! 0
(1 row)
-- via a VIEW
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/stats.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/stats.out Thu Jan 11 20:13:07 2018
***************
*** 25,30 ****
--- 25,31 ----
FROM pg_catalog.pg_stat_user_tables AS t,
pg_catalog.pg_statio_user_tables AS b
WHERE t.relname='tenk2' AND b.relname='tenk2';
+ ERROR: bigint out of range
-- function to wait for counters to advance
create function wait_for_stats() returns void as $$
declare
***************
*** 154,164 ****
\c -
-- wait for stats collector to update
SELECT wait_for_stats();
! wait_for_stats
! ----------------
!
! (1 row)
!
-- check effects
SELECT relname, n_tup_ins, n_tup_upd, n_tup_del, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
--- 155,166 ----
\c -
-- wait for stats collector to update
SELECT wait_for_stats();
! ERROR: relation "prevstats" does not exist
! LINE 1: ... FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats ...
! ^
! QUERY: SELECT (st.seq_scan >= pr.seq_scan + 1) FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
! WHERE st.relname='tenk2' AND cl.relname='tenk2'
! CONTEXT: PL/pgSQL function wait_for_stats() line 18 at SQL statement
-- check effects
SELECT relname, n_tup_ins, n_tup_upd, n_tup_del, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
***************
*** 165,175 ****
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
! trunc_stats_test | 3 | 0 | 0 | 0 | 0
! trunc_stats_test1 | 4 | 2 | 1 | 1 | 0
! trunc_stats_test2 | 1 | 0 | 0 | 1 | 0
! trunc_stats_test3 | 4 | 0 | 0 | 2 | 2
! trunc_stats_test4 | 2 | 0 | 0 | 0 | 2
(5 rows)
SELECT st.seq_scan >= pr.seq_scan + 1,
--- 167,177 ----
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
! trunc_stats_test | 0 | 0 | 0 | 0 | 0
! trunc_stats_test1 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test2 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test3 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test4 | 0 | 0 | 0 | 0 | 0
(5 rows)
SELECT st.seq_scan >= pr.seq_scan + 1,
***************
*** 178,204 ****
st.idx_tup_fetch >= pr.idx_tup_fetch + 1
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ?column? | ?column? | ?column? | ?column?
! ----------+----------+----------+----------
! t | t | t | t
! (1 row)
!
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1
FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ?column? | ?column?
! ----------+----------
! t | t
! (1 row)
!
SELECT pr.snap_ts < pg_stat_get_snapshot_timestamp() as snapshot_newer
FROM prevstats AS pr;
! snapshot_newer
! ----------------
! t
! (1 row)
!
DROP TABLE trunc_stats_test, trunc_stats_test1, trunc_stats_test2, trunc_stats_test3, trunc_stats_test4;
DROP TABLE prevstats;
-- End of Stats Test
--- 180,201 ----
st.idx_tup_fetch >= pr.idx_tup_fetch + 1
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ERROR: relation "prevstats" does not exist
! LINE 5: FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats ...
! ^
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1
FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ERROR: relation "prevstats" does not exist
! LINE 3: ...FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats ...
! ^
SELECT pr.snap_ts < pg_stat_get_snapshot_timestamp() as snapshot_newer
FROM prevstats AS pr;
! ERROR: relation "prevstats" does not exist
! LINE 2: FROM prevstats AS pr;
! ^
DROP TABLE trunc_stats_test, trunc_stats_test1, trunc_stats_test2, trunc_stats_test3, trunc_stats_test4;
DROP TABLE prevstats;
+ ERROR: table "prevstats" does not exist
-- End of Stats Test
======================================================================
regression.out (text/plain, 8.7K) download
test tablespace ... ok
parallel group (20 tests): oid float4 float8 varchar text int2 name char boolean bit txid int4 int8 money uuid regproc pg_lsn enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
pg_lsn ... ok
regproc ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): date time circle path line point lseg timetz abstime macaddr reltime tinterval macaddr8 inet interval timestamp tstypes timestamptz box polygon
point ... ok
lseg ... ok
line ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
macaddr8 ... ok
tstypes ... ok
parallel group (9 tests): geometry expressions comments misc_sanity horology type_sanity oidjoins opr_sanity regex
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
misc_sanity ... ok
comments ... ok
expressions ... ok
test insert ... ok
test insert_conflict ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (3 tests): copyselect copydml copy
copy ... ok
copyselect ... ok
copydml ... ok
parallel group (3 tests): create_operator create_procedure create_misc
create_misc ... ok
create_operator ... ok
create_procedure ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (15 tests): create_function_3 create_cast create_aggregate roleattributes hash_func drop_if_exists typed_table create_am constraints rolenames vacuum create_table_like inherit updatable_views triggers
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
rolenames ... ok
roleattributes ... ok
create_am ... ok
hash_func ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): random select_into case select_having select_distinct select_implicit select_distinct_on delete namespace btree_index prepared_xacts transactions portals union subselect update arrays aggregates hash_index join
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 ... ok
transactions ... ok
random ... failed (ignored)
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (17 tests): init_privs security_label lock drop_operator password tablesample replica_identity object_address groupingsets collate privileges matview brin spgist gin rowsecurity gist
brin ... ok
gin ... ok
gist ... ok
spgist ... ok
privileges ... ok
init_privs ... ok
security_label ... ok
collate ... ok
matview ... ok
lock ... ok
replica_identity ... ok
rowsecurity ... ok
object_address ... ok
tablesample ... ok
groupingsets ... FAILED
drop_operator ... ok
password ... ok
parallel group (11 tests): psql dbsize misc_functions async alter_operator tidscan alter_generic tsrf sysviews misc stats_ext
alter_generic ... ok
alter_operator ... ok
misc ... ok
psql ... ok
async ... ok
dbsize ... ok
misc_functions ... ok
sysviews ... ok
tsrf ... FAILED
tidscan ... ok
stats_ext ... ok
parallel group (3 tests): amutils psql_crosstab rules
rules ... ok
psql_crosstab ... ok
amutils ... ok
test select_parallel ... FAILED
test write_parallel ... ok
parallel group (2 tests): subscription publication
publication ... ok
subscription ... ok
parallel group (20 tests): select_views xmlmap advisory_lock guc dependency tsdicts combocid portals_p2 json_encoding functional_deps equivclass tsearch json window cluster jsonb bitmapops indirect_toast foreign_key foreign_data
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... FAILED
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
jsonb ... ok
json_encoding ... ok
indirect_toast ... ok
equivclass ... ok
parallel group (19 tests): temp prepare plancache conversion limit without_oid returning copy2 truncate rangefuncs polymorphism with rowtypes sequence domain largeobject xml alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... FAILED
xml ... ok
parallel group (5 tests): hash_part reloptions identity partition_prune partition_join
identity ... ok
partition_join ... ok
partition_prune ... ok
reloptions ... ok
hash_part ... ok
test event_trigger ... ok
test stats ... FAILED
* Re: master make check fails on Solaris 10
@ 2018-01-11 17:34 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
1 sibling, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-11 17:34 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: pgsql-hackers
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> Hello, hackers! I got a permanent failure of master (commit
> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
> Regression output and diffs are attached.
Hm, buildfarm member protosciurus is running a similar configuration
without problems. Looking at its configuration, maybe you need to
fool with LD_LIBRARY_PATH and/or LDFLAGS_SL?
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-11 17:39 Andres Freund <andres@anarazel.de>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
1 sibling, 1 reply; 46+ messages in thread
From: Andres Freund @ 2018-01-11 17:39 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: pgsql-hackers
Hi,
On 2018-01-11 20:21:11 +0300, Marina Polyakova wrote:
> Hello, hackers! I got a permanent failure of master (commit
> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Did this use to work? If so, could you check whether it worked before
69c3936a1499b772a749ae629fc59b2d72722332?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-12 08:37 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-12 08:37 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
On 11-01-2018 20:34, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> Hello, hackers! I got a permanent failure of master (commit
>> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
>> Regression output and diffs are attached.
>
> Hm, buildfarm member protosciurus is running a similar configuration
> without problems. Looking at its configuration, maybe you need to
> fool with LD_LIBRARY_PATH and/or LDFLAGS_SL?
I added these parameters with the same values in configure
(LDFLAGS_SL="-m64"
LD_LIBRARY_PATH="/lib/64:/usr/lib/64:/usr/sfw/lib/64:/usr/local/lib"),
there're the same failures :( (see the attached regression diffs and
output)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
other_config_regression.diffs (text/x-diff, 30.7K) download
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/random.out Fri Jan 12 10:59:09 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/random.out Fri Jan 12 11:23:56 2018
***************
*** 46,52 ****
SELECT AVG(random) FROM RANDOM_TBL
HAVING AVG(random) NOT BETWEEN 80 AND 120;
! avg
! -----
! (0 rows)
--- 46,53 ----
SELECT AVG(random) FROM RANDOM_TBL
HAVING AVG(random) NOT BETWEEN 80 AND 120;
! avg
! ----------------------
! 13835058055282163712
! (1 row)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/groupingsets.out Fri Jan 12 10:59:08 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/groupingsets.out Fri Jan 12 11:24:35 2018
***************
*** 143,156 ****
-- nesting with window functions
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by rollup (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | | 12 | 36
(6 rows)
-- nesting with grouping sets
--- 143,156 ----
-- nesting with window functions
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by rollup (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79507068872943528402422333440
! 1 | | 10 | 159014137745887056804844666880
! 2 | 2 | 2 | 238521206618830585207267000320
! 2 | | 2 | 318028275491774113609689333760
! | | 12 | 397535344364717642012111667200
(6 rows)
-- nesting with grouping sets
***************
*** 544,559 ****
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | 1 | 8 | 32
! | 2 | 4 | 36
! | | 12 | 48
(8 rows)
select a, b, sum(c) from (values (1,1,10),(1,1,11),(1,2,12),(1,2,13),(1,3,14),(2,3,15),(3,3,16),(3,4,17),(4,1,18),(4,1,19)) v(a,b,c) group by rollup (a,b);
--- 544,559 ----
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79523145874486552930199535616
! 1 | | 10 | 159046291748973105860399071232
! 2 | 2 | 2 | 238569437623459658790598606848
! 2 | | 2 | 318092583497946211720798142464
! | 1 | 8 | 397615729372432764650997678080
! | 2 | 4 | 477138875246919317581197213696
! | | 12 | 556662021121405870511396749312
(8 rows)
select a, b, sum(c) from (values (1,1,10),(1,1,11),(1,2,12),(1,2,13),(1,3,14),(2,3,15),(3,3,16),(3,4,17),(4,1,18),(4,1,19)) v(a,b,c) group by rollup (a,b);
***************
*** 1219,1234 ****
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | 1 | 8 | 32
! | 2 | 4 | 36
! | | 12 | 48
(8 rows)
explain (costs off)
--- 1219,1234 ----
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79525570219379696134311116800
! 1 | | 10 | 159051140438759392268622233600
! 2 | 2 | 2 | 238576710658139088402933350400
! 2 | | 2 | 318102280877518784537244467200
! | 1 | 8 | 397627851096898480671555584000
! | 2 | 4 | 477153421316278176805866700800
! | | 12 | 556678991535657872940177817600
(8 rows)
explain (costs off)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/tsrf.out Fri Jan 12 10:59:10 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/tsrf.out Fri Jan 12 11:24:55 2018
***************
*** 251,259 ****
SELECT SUM(count(*)) OVER(PARTITION BY generate_series(1,3) ORDER BY generate_series(1,3)), generate_series(1,3) g FROM few GROUP BY g;
sum | g
-----+---
! 3 | 1
! 3 | 2
! 3 | 3
(3 rows)
-- sorting + grouping
--- 251,259 ----
SELECT SUM(count(*)) OVER(PARTITION BY generate_series(1,3) ORDER BY generate_series(1,3)), generate_series(1,3) g FROM few GROUP BY g;
sum | g
-----+---
! 0 | 1
! 0 | 2
! 0 | 3
(3 rows)
-- sorting + grouping
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/select_parallel.out Fri Jan 12 10:59:09 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/select_parallel.out Fri Jan 12 11:25:27 2018
***************
*** 722,730 ****
(5 rows)
select avg(unique1::int8) from tenk1;
! avg
! -----------------------
! 4999.5000000000000000
(1 row)
-- gather merge test with a LIMIT
--- 722,730 ----
(5 rows)
select avg(unique1::int8) from tenk1;
! avg
! -------------------------------
! 79295891141614032158731083029
(1 row)
-- gather merge test with a LIMIT
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/window.out Fri Jan 12 10:59:10 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/window.out Fri Jan 12 11:25:38 2018
***************
*** 51,78 ****
-- with GROUP BY
SELECT four, ten, SUM(SUM(four)) OVER (PARTITION BY four), AVG(ten) FROM tenk1
GROUP BY four, ten ORDER BY four, ten;
! four | ten | sum | avg
! ------+-----+------+------------------------
! 0 | 0 | 0 | 0.00000000000000000000
! 0 | 2 | 0 | 2.0000000000000000
! 0 | 4 | 0 | 4.0000000000000000
! 0 | 6 | 0 | 6.0000000000000000
! 0 | 8 | 0 | 8.0000000000000000
! 1 | 1 | 2500 | 1.00000000000000000000
! 1 | 3 | 2500 | 3.0000000000000000
! 1 | 5 | 2500 | 5.0000000000000000
! 1 | 7 | 2500 | 7.0000000000000000
! 1 | 9 | 2500 | 9.0000000000000000
! 2 | 0 | 5000 | 0.00000000000000000000
! 2 | 2 | 5000 | 2.0000000000000000
! 2 | 4 | 5000 | 4.0000000000000000
! 2 | 6 | 5000 | 6.0000000000000000
! 2 | 8 | 5000 | 8.0000000000000000
! 3 | 1 | 7500 | 1.00000000000000000000
! 3 | 3 | 7500 | 3.0000000000000000
! 3 | 5 | 7500 | 5.0000000000000000
! 3 | 7 | 7500 | 7.0000000000000000
! 3 | 9 | 7500 | 9.0000000000000000
(20 rows)
SELECT depname, empno, salary, sum(salary) OVER w FROM empsalary WINDOW w AS (PARTITION BY depname);
--- 51,78 ----
-- with GROUP BY
SELECT four, ten, SUM(SUM(four)) OVER (PARTITION BY four), AVG(ten) FROM tenk1
GROUP BY four, ten ORDER BY four, ten;
! four | ten | sum | avg
! ------+-----+--------------------------------+------------------------
! 0 | 0 | 318029204617379618212385128448 | 0.00000000000000000000
! 0 | 2 | 318029204617379618212385128448 | 2.0000000000000000
! 0 | 4 | 318029204617379618212385128448 | 4.0000000000000000
! 0 | 6 | 318029204617379618212385128448 | 6.0000000000000000
! 0 | 8 | 318029204617379618212385128448 | 8.0000000000000000
! 1 | 1 | 318029204617379618212385128448 | 1.00000000000000000000
! 1 | 3 | 318029204617379618212385128448 | 3.0000000000000000
! 1 | 5 | 318029204617379618212385128448 | 5.0000000000000000
! 1 | 7 | 318029204617379618212385128448 | 7.0000000000000000
! 1 | 9 | 318029204617379618212385128448 | 9.0000000000000000
! 2 | 0 | 318029204617379618212385128448 | 0.00000000000000000000
! 2 | 2 | 318029204617379618212385128448 | 2.0000000000000000
! 2 | 4 | 318029204617379618212385128448 | 4.0000000000000000
! 2 | 6 | 318029204617379618212385128448 | 6.0000000000000000
! 2 | 8 | 318029204617379618212385128448 | 8.0000000000000000
! 3 | 1 | 318029204617379618212385128448 | 1.00000000000000000000
! 3 | 3 | 318029204617379618212385128448 | 3.0000000000000000
! 3 | 5 | 318029204617379618212385128448 | 5.0000000000000000
! 3 | 7 | 318029204617379618212385128448 | 7.0000000000000000
! 3 | 9 | 318029204617379618212385128448 | 9.0000000000000000
(20 rows)
SELECT depname, empno, salary, sum(salary) OVER w FROM empsalary WINDOW w AS (PARTITION BY depname);
***************
*** 411,428 ****
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER (PARTITION BY two ORDER BY ten) AS wsum
FROM tenk1 GROUP BY ten, two;
! ten | two | gsum | wsum
! -----+-----+-------+--------
! 0 | 0 | 45000 | 45000
! 2 | 0 | 47000 | 92000
! 4 | 0 | 49000 | 141000
! 6 | 0 | 51000 | 192000
! 8 | 0 | 53000 | 245000
! 1 | 1 | 46000 | 46000
! 3 | 1 | 48000 | 94000
! 5 | 1 | 50000 | 144000
! 7 | 1 | 52000 | 196000
! 9 | 1 | 54000 | 250000
(10 rows)
SELECT count(*) OVER (PARTITION BY four), four FROM (SELECT * FROM tenk1 WHERE two = 1)s WHERE unique2 < 10;
--- 411,428 ----
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER (PARTITION BY two ORDER BY ten) AS wsum
FROM tenk1 GROUP BY ten, two;
! ten | two | gsum | wsum
! -----+-----+-------+--------------------------------
! 0 | 0 | 45000 | 0
! 2 | 0 | 47000 | 79507287872689171482219118592
! 4 | 0 | 49000 | 159014575745378342964438237184
! 6 | 0 | 51000 | 238521863618067514446657355776
! 8 | 0 | 53000 | 318029151490756685928876474368
! 1 | 1 | 46000 | 0
! 3 | 1 | 48000 | 79507287872689171482219118592
! 5 | 1 | 50000 | 159014575745378342964438237184
! 7 | 1 | 52000 | 238521863618067514446657355776
! 9 | 1 | 54000 | 318029151490756685928876474368
(10 rows)
SELECT count(*) OVER (PARTITION BY four), four FROM (SELECT * FROM tenk1 WHERE two = 1)s WHERE unique2 < 10;
***************
*** 483,500 ****
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER win AS wsum
FROM tenk1 GROUP BY ten, two WINDOW win AS (PARTITION BY two ORDER BY ten);
! ten | two | gsum | wsum
! -----+-----+-------+--------
! 0 | 0 | 45000 | 45000
! 2 | 0 | 47000 | 92000
! 4 | 0 | 49000 | 141000
! 6 | 0 | 51000 | 192000
! 8 | 0 | 53000 | 245000
! 1 | 1 | 46000 | 46000
! 3 | 1 | 48000 | 94000
! 5 | 1 | 50000 | 144000
! 7 | 1 | 52000 | 196000
! 9 | 1 | 54000 | 250000
(10 rows)
-- more than one window with GROUP BY
--- 483,500 ----
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER win AS wsum
FROM tenk1 GROUP BY ten, two WINDOW win AS (PARTITION BY two ORDER BY ten);
! ten | two | gsum | wsum
! -----+-----+-------+--------------------------------
! 0 | 0 | 45000 | 0
! 2 | 0 | 47000 | 79507287872689171482219118592
! 4 | 0 | 49000 | 159014575745378342964438237184
! 6 | 0 | 51000 | 238521863618067514446657355776
! 8 | 0 | 53000 | 318029151490756685928876474368
! 1 | 1 | 46000 | 0
! 3 | 1 | 48000 | 79507287872689171482219118592
! 5 | 1 | 50000 | 159014575745378342964438237184
! 7 | 1 | 52000 | 238521863618067514446657355776
! 9 | 1 | 54000 | 318029151490756685928876474368
(10 rows)
-- more than one window with GROUP BY
***************
*** 502,512 ****
row_number() OVER (ORDER BY depname),
sum(sum(salary)) OVER (ORDER BY depname DESC)
FROM empsalary GROUP BY depname;
! sum | row_number | sum
! -------+------------+-------
! 14600 | 3 | 14600
! 7400 | 2 | 22000
! 25100 | 1 | 47100
(3 rows)
-- identical windows with different names
--- 502,512 ----
row_number() OVER (ORDER BY depname),
sum(sum(salary)) OVER (ORDER BY depname DESC)
FROM empsalary GROUP BY depname;
! sum | row_number | sum
! -------+------------+--------------------------------
! 14600 | 3 | 0
! 7400 | 2 | 79507287872689171482219118592
! 25100 | 1 | 159014575745378342964438237184
(3 rows)
-- identical windows with different names
***************
*** 1027,1037 ****
) FILTER (WHERE depname <> 'sales') OVER (ORDER BY depname DESC) AS "filtered_sum",
depname
FROM empsalary GROUP BY depname;
! sum | row_number | filtered_sum | depname
! -------+------------+--------------+-----------
! 14600 | 3 | | sales
! 7400 | 2 | 3500 | personnel
! 25100 | 1 | 22600 | develop
(3 rows)
-- Test pushdown of quals into a subquery containing window functions
--- 1027,1037 ----
) FILTER (WHERE depname <> 'sales') OVER (ORDER BY depname DESC) AS "filtered_sum",
depname
FROM empsalary GROUP BY depname;
! sum | row_number | filtered_sum | depname
! -------+------------+-------------------------------+-----------
! 14600 | 3 | | sales
! 7400 | 2 | 0 | personnel
! 25100 | 1 | 79507287872689171482219118592 | develop
(3 rows)
-- Test pushdown of quals into a subquery containing window functions
***************
*** 1341,1352 ****
-- test inverse transition functions handle NULLs properly
SELECT i,AVG(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | avg
! ---+--------------------
! 1 | 1.5000000000000000
! 2 | 2.0000000000000000
! 3 |
! 4 |
(4 rows)
SELECT i,AVG(v::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1341,1352 ----
-- test inverse transition functions handle NULLs properly
SELECT i,AVG(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | avg
! ---+-------------------------------
! 1 | 39753643936344585741109559296
! 2 | 0.00000000000000000000
! 3 |
! 4 |
(4 rows)
SELECT i,AVG(v::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1411,1422 ****
SELECT i,SUM(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | sum
! ---+-----
! 1 | 3
! 2 | 2
! 3 |
! 4 |
(4 rows)
SELECT i,SUM(v::money) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1411,1422 ----
SELECT i,SUM(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | sum
! ---+-------------------------------
! 1 | 79507287872689171482219118592
! 2 | 0
! 3 |
! 4 |
(4 rows)
SELECT i,SUM(v::money) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1491,1514 ****
SELECT VAR_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! -----------------------
! 21704.000000000000
! 13868.750000000000
! 11266.666666666667
! 4225.0000000000000000
! 0
(5 rows)
SELECT VAR_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! -----------------------
! 21704.000000000000
! 13868.750000000000
! 11266.666666666667
! 4225.0000000000000000
! 0
(5 rows)
SELECT VAR_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1491,1514 ----
SELECT VAR_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! ---------
! 0
! 0
! 0
! 0
! 0
(5 rows)
SELECT VAR_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! ---------
! 0
! 0
! 0
! 0
! 0
(5 rows)
SELECT VAR_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1535,1558 ****
SELECT VAR_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VAR_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VAR_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1535,1558 ----
SELECT VAR_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VAR_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VAR_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1579,1602 ****
SELECT VARIANCE(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VARIANCE(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VARIANCE(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1579,1602 ----
SELECT VARIANCE(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VARIANCE(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VARIANCE(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1624,1649 ****
SELECT STDDEV_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ---------------------
! 147.322774885623
! 147.322774885623
! 117.765657133139
! 106.144555520604
! 65.0000000000000000
! 0
(6 rows)
SELECT STDDEV_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ---------------------
! 147.322774885623
! 147.322774885623
! 117.765657133139
! 106.144555520604
! 65.0000000000000000
! 0
(6 rows)
SELECT STDDEV_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1624,1649 ----
SELECT STDDEV_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ------------
! 0
! 0
! 0
! 0
! 0
! 0
(6 rows)
SELECT STDDEV_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ------------
! 0
! 0
! 0
! 0
! 0
! 0
(6 rows)
SELECT STDDEV_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1672,1697 ****
SELECT STDDEV_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1672,1697 ----
SELECT STDDEV_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! -------------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! -------------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1720,1745 ****
SELECT STDDEV(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1720,1745 ----
SELECT STDDEV(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! --------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! --------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/with.out Fri Jan 12 10:59:10 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/with.out Fri Jan 12 11:25:57 2018
***************
*** 285,291 ****
SELECT count(*) FROM q1 WHERE y > (SELECT sum(y)/100 FROM q1 qsub);
count
-------
! 50
(1 row)
-- via a VIEW
--- 285,291 ----
SELECT count(*) FROM q1 WHERE y > (SELECT sum(y)/100 FROM q1 qsub);
count
-------
! 0
(1 row)
-- via a VIEW
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/expected/stats.out Fri Jan 12 10:59:10 2018
--- /home/buildfarm/mpolyakova/postgresql_master_other_config/src/test/regress/results/stats.out Fri Jan 12 11:26:24 2018
***************
*** 25,30 ****
--- 25,31 ----
FROM pg_catalog.pg_stat_user_tables AS t,
pg_catalog.pg_statio_user_tables AS b
WHERE t.relname='tenk2' AND b.relname='tenk2';
+ ERROR: bigint out of range
-- function to wait for counters to advance
create function wait_for_stats() returns void as $$
declare
***************
*** 154,164 ****
\c -
-- wait for stats collector to update
SELECT wait_for_stats();
! wait_for_stats
! ----------------
!
! (1 row)
!
-- check effects
SELECT relname, n_tup_ins, n_tup_upd, n_tup_del, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
--- 155,166 ----
\c -
-- wait for stats collector to update
SELECT wait_for_stats();
! ERROR: relation "prevstats" does not exist
! LINE 1: ... FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats ...
! ^
! QUERY: SELECT (st.seq_scan >= pr.seq_scan + 1) FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
! WHERE st.relname='tenk2' AND cl.relname='tenk2'
! CONTEXT: PL/pgSQL function wait_for_stats() line 18 at SQL statement
-- check effects
SELECT relname, n_tup_ins, n_tup_upd, n_tup_del, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
***************
*** 165,175 ****
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
! trunc_stats_test | 3 | 0 | 0 | 0 | 0
! trunc_stats_test1 | 4 | 2 | 1 | 1 | 0
! trunc_stats_test2 | 1 | 0 | 0 | 1 | 0
! trunc_stats_test3 | 4 | 0 | 0 | 2 | 2
! trunc_stats_test4 | 2 | 0 | 0 | 0 | 2
(5 rows)
SELECT st.seq_scan >= pr.seq_scan + 1,
--- 167,177 ----
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
! trunc_stats_test | 0 | 0 | 0 | 0 | 0
! trunc_stats_test1 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test2 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test3 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test4 | 0 | 0 | 0 | 0 | 0
(5 rows)
SELECT st.seq_scan >= pr.seq_scan + 1,
***************
*** 178,204 ****
st.idx_tup_fetch >= pr.idx_tup_fetch + 1
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ?column? | ?column? | ?column? | ?column?
! ----------+----------+----------+----------
! t | t | t | t
! (1 row)
!
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1
FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ?column? | ?column?
! ----------+----------
! t | t
! (1 row)
!
SELECT pr.snap_ts < pg_stat_get_snapshot_timestamp() as snapshot_newer
FROM prevstats AS pr;
! snapshot_newer
! ----------------
! t
! (1 row)
!
DROP TABLE trunc_stats_test, trunc_stats_test1, trunc_stats_test2, trunc_stats_test3, trunc_stats_test4;
DROP TABLE prevstats;
-- End of Stats Test
--- 180,201 ----
st.idx_tup_fetch >= pr.idx_tup_fetch + 1
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ERROR: relation "prevstats" does not exist
! LINE 5: FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats ...
! ^
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1
FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ERROR: relation "prevstats" does not exist
! LINE 3: ...FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats ...
! ^
SELECT pr.snap_ts < pg_stat_get_snapshot_timestamp() as snapshot_newer
FROM prevstats AS pr;
! ERROR: relation "prevstats" does not exist
! LINE 2: FROM prevstats AS pr;
! ^
DROP TABLE trunc_stats_test, trunc_stats_test1, trunc_stats_test2, trunc_stats_test3, trunc_stats_test4;
DROP TABLE prevstats;
+ ERROR: table "prevstats" does not exist
-- End of Stats Test
======================================================================
other_config_regression.out (text/plain, 8.7K) download
test tablespace ... ok
parallel group (20 tests): text int2 boolean name varchar char oid int4 float4 int8 uuid money txid bit regproc float8 pg_lsn enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
pg_lsn ... ok
regproc ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): date time circle path line point lseg abstime timetz tinterval reltime box macaddr interval macaddr8 timestamptz tstypes inet timestamp polygon
point ... ok
lseg ... ok
line ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
macaddr8 ... ok
tstypes ... ok
parallel group (9 tests): misc_sanity comments geometry horology expressions type_sanity oidjoins opr_sanity regex
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
misc_sanity ... ok
comments ... ok
expressions ... ok
test insert ... ok
test insert_conflict ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (3 tests): copyselect copydml copy
copy ... ok
copyselect ... ok
copydml ... ok
parallel group (3 tests): create_operator create_procedure create_misc
create_misc ... ok
create_operator ... ok
create_procedure ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (15 tests): drop_if_exists create_function_3 create_aggregate create_cast roleattributes create_am hash_func constraints typed_table rolenames vacuum create_table_like inherit updatable_views triggers
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
rolenames ... ok
roleattributes ... ok
create_am ... ok
hash_func ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): btree_index random case select_into select_having select_distinct select_implicit select_distinct_on namespace transactions delete subselect prepared_xacts update portals union aggregates arrays hash_index join
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 ... ok
transactions ... ok
random ... failed (ignored)
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (17 tests): lock security_label init_privs drop_operator password replica_identity tablesample collate object_address groupingsets privileges brin matview spgist gin rowsecurity gist
brin ... ok
gin ... ok
gist ... ok
spgist ... ok
privileges ... ok
init_privs ... ok
security_label ... ok
collate ... ok
matview ... ok
lock ... ok
replica_identity ... ok
rowsecurity ... ok
object_address ... ok
tablesample ... ok
groupingsets ... FAILED
drop_operator ... ok
password ... ok
parallel group (11 tests): alter_operator async tsrf misc_functions dbsize psql tidscan alter_generic sysviews misc stats_ext
alter_generic ... ok
alter_operator ... ok
misc ... ok
psql ... ok
async ... ok
dbsize ... ok
misc_functions ... ok
sysviews ... ok
tsrf ... FAILED
tidscan ... ok
stats_ext ... ok
parallel group (3 tests): amutils psql_crosstab rules
rules ... ok
psql_crosstab ... ok
amutils ... ok
test select_parallel ... FAILED
test write_parallel ... ok
parallel group (2 tests): subscription publication
publication ... ok
subscription ... ok
parallel group (20 tests): dependency tsdicts combocid guc portals_p2 select_views xmlmap advisory_lock json_encoding functional_deps cluster equivclass json window tsearch jsonb bitmapops indirect_toast foreign_key foreign_data
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... FAILED
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
jsonb ... ok
json_encoding ... ok
indirect_toast ... ok
equivclass ... ok
parallel group (19 tests): prepare conversion limit plancache copy2 temp returning without_oid sequence polymorphism with truncate rowtypes domain rangefuncs largeobject xml alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... FAILED
xml ... ok
parallel group (5 tests): reloptions hash_part identity partition_prune partition_join
identity ... ok
partition_join ... ok
partition_prune ... ok
reloptions ... ok
hash_part ... ok
test event_trigger ... ok
test stats ... FAILED
* Re: master make check fails on Solaris 10
@ 2018-01-12 11:05 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-12 11:05 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers
On 11-01-2018 20:39, Andres Freund wrote:
> Hi,
>
> On 2018-01-11 20:21:11 +0300, Marina Polyakova wrote:
>> Hello, hackers! I got a permanent failure of master (commit
>> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
>
> Did this use to work?
It always fails if you have asked about this..
> If so, could you check whether it worked before
> 69c3936a1499b772a749ae629fc59b2d72722332?
- on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) the
same failures occur (see the attached regression diffs and output);
- on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
passes.
I'll try to find out from what commit it started.. Don't you have any
suspicions?)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
272c2ab_regression.diffs (text/x-diff, 30.6K) download
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/random.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/random.out Fri Jan 12 12:37:28 2018
***************
*** 46,52 ****
SELECT AVG(random) FROM RANDOM_TBL
HAVING AVG(random) NOT BETWEEN 80 AND 120;
! avg
! -----
! (0 rows)
--- 46,53 ----
SELECT AVG(random) FROM RANDOM_TBL
HAVING AVG(random) NOT BETWEEN 80 AND 120;
! avg
! -------------------------------
! 59630855721112644241909088256
! (1 row)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/groupingsets.out Thu Jan 11 19:37:50 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/groupingsets.out Fri Jan 12 12:38:07 2018
***************
*** 143,156 ****
-- nesting with window functions
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by rollup (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | | 12 | 36
(6 rows)
-- nesting with grouping sets
--- 143,156 ----
-- nesting with window functions
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by rollup (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79489175236044124958001987584
! 1 | | 10 | 158978350472088249916003975168
! 2 | 2 | 2 | 238467525708132374874005962752
! 2 | | 2 | 317956700944176499832007950336
! | | 12 | 397445876180220624790009937920
(6 rows)
-- nesting with grouping sets
***************
*** 544,559 ****
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | 1 | 8 | 32
! | 2 | 4 | 36
! | | 12 | 48
(8 rows)
select a, b, sum(c) from (values (1,1,10),(1,1,11),(1,2,12),(1,2,13),(1,3,14),(2,3,15),(3,3,16),(3,4,17),(4,1,18),(4,1,19)) v(a,b,c) group by rollup (a,b);
--- 544,559 ----
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79523211102173597567174049792
! 1 | | 10 | 159046422204347195134348099584
! 2 | 2 | 2 | 238569633306520792701522149376
! 2 | | 2 | 318092844408694390268696199168
! | 1 | 8 | 397616055510867987835870248960
! | 2 | 4 | 477139266613041585403044298752
! | | 12 | 556662477715215182970218348544
(8 rows)
select a, b, sum(c) from (values (1,1,10),(1,1,11),(1,2,12),(1,2,13),(1,3,14),(2,3,15),(3,3,16),(3,4,17),(4,1,18),(4,1,19)) v(a,b,c) group by rollup (a,b);
***************
*** 1219,1234 ****
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+------
! 1 | 1 | 8 | 8
! 1 | 2 | 2 | 10
! 1 | | 10 | 20
! 2 | 2 | 2 | 22
! 2 | | 2 | 24
! | 1 | 8 | 32
! | 2 | 4 | 36
! | | 12 | 48
(8 rows)
explain (costs off)
--- 1219,1234 ----
select a, b, sum(c), sum(sum(c)) over (order by a,b) as rsum
from gstest2 group by cube (a,b) order by rsum, a, b;
! a | b | sum | rsum
! ---+---+-----+--------------------------------
! 1 | 1 | 8 | 0
! 1 | 2 | 2 | 79526240205124453265225809920
! 1 | | 10 | 159052480410248906530451619840
! 2 | 2 | 2 | 238578720615373359795677429760
! 2 | | 2 | 318104960820497813060903239680
! | 1 | 8 | 397631201025622266326129049600
! | 2 | 4 | 477157441230746719591354859520
! | | 12 | 556683681435871172856580669440
(8 rows)
explain (costs off)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/tsrf.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/tsrf.out Fri Jan 12 12:38:28 2018
***************
*** 251,259 ****
SELECT SUM(count(*)) OVER(PARTITION BY generate_series(1,3) ORDER BY generate_series(1,3)), generate_series(1,3) g FROM few GROUP BY g;
sum | g
-----+---
! 3 | 1
! 3 | 2
! 3 | 3
(3 rows)
-- sorting + grouping
--- 251,259 ----
SELECT SUM(count(*)) OVER(PARTITION BY generate_series(1,3) ORDER BY generate_series(1,3)), generate_series(1,3) g FROM few GROUP BY g;
sum | g
-----+---
! 0 | 1
! 0 | 2
! 0 | 3
(3 rows)
-- sorting + grouping
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/select_parallel.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/select_parallel.out Fri Jan 12 12:39:00 2018
***************
*** 722,730 ****
(5 rows)
select avg(unique1::int8) from tenk1;
! avg
! -----------------------
! 4999.5000000000000000
(1 row)
-- gather merge test with a LIMIT
--- 722,730 ----
(5 rows)
select avg(unique1::int8) from tenk1;
! avg
! -------------------------------
! 79499661626572135089033082149
(1 row)
-- gather merge test with a LIMIT
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/window.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/window.out Fri Jan 12 12:39:09 2018
***************
*** 51,78 ****
-- with GROUP BY
SELECT four, ten, SUM(SUM(four)) OVER (PARTITION BY four), AVG(ten) FROM tenk1
GROUP BY four, ten ORDER BY four, ten;
! four | ten | sum | avg
! ------+-----+------+------------------------
! 0 | 0 | 0 | 0.00000000000000000000
! 0 | 2 | 0 | 2.0000000000000000
! 0 | 4 | 0 | 4.0000000000000000
! 0 | 6 | 0 | 6.0000000000000000
! 0 | 8 | 0 | 8.0000000000000000
! 1 | 1 | 2500 | 1.00000000000000000000
! 1 | 3 | 2500 | 3.0000000000000000
! 1 | 5 | 2500 | 5.0000000000000000
! 1 | 7 | 2500 | 7.0000000000000000
! 1 | 9 | 2500 | 9.0000000000000000
! 2 | 0 | 5000 | 0.00000000000000000000
! 2 | 2 | 5000 | 2.0000000000000000
! 2 | 4 | 5000 | 4.0000000000000000
! 2 | 6 | 5000 | 6.0000000000000000
! 2 | 8 | 5000 | 8.0000000000000000
! 3 | 1 | 7500 | 1.00000000000000000000
! 3 | 3 | 7500 | 3.0000000000000000
! 3 | 5 | 7500 | 5.0000000000000000
! 3 | 7 | 7500 | 7.0000000000000000
! 3 | 9 | 7500 | 9.0000000000000000
(20 rows)
SELECT depname, empno, salary, sum(salary) OVER w FROM empsalary WINDOW w AS (PARTITION BY depname);
--- 51,78 ----
-- with GROUP BY
SELECT four, ten, SUM(SUM(four)) OVER (PARTITION BY four), AVG(ten) FROM tenk1
GROUP BY four, ten ORDER BY four, ten;
! four | ten | sum | avg
! ------+-----+--------------------------------+------------------------
! 0 | 0 | 318028861065217989445695832064 | 0.00000000000000000000
! 0 | 2 | 318028861065217989445695832064 | 2.0000000000000000
! 0 | 4 | 318028861065217989445695832064 | 4.0000000000000000
! 0 | 6 | 318028861065217989445695832064 | 6.0000000000000000
! 0 | 8 | 318028861065217989445695832064 | 8.0000000000000000
! 1 | 1 | 318028861065217989445695832064 | 1.00000000000000000000
! 1 | 3 | 318028861065217989445695832064 | 3.0000000000000000
! 1 | 5 | 318028861065217989445695832064 | 5.0000000000000000
! 1 | 7 | 318028861065217989445695832064 | 7.0000000000000000
! 1 | 9 | 318028861065217989445695832064 | 9.0000000000000000
! 2 | 0 | 318028861065217989445695832064 | 0.00000000000000000000
! 2 | 2 | 318028861065217989445695832064 | 2.0000000000000000
! 2 | 4 | 318028861065217989445695832064 | 4.0000000000000000
! 2 | 6 | 318028861065217989445695832064 | 6.0000000000000000
! 2 | 8 | 318028861065217989445695832064 | 8.0000000000000000
! 3 | 1 | 318028861065217989445695832064 | 1.00000000000000000000
! 3 | 3 | 318028861065217989445695832064 | 3.0000000000000000
! 3 | 5 | 318028861065217989445695832064 | 5.0000000000000000
! 3 | 7 | 318028861065217989445695832064 | 7.0000000000000000
! 3 | 9 | 318028861065217989445695832064 | 9.0000000000000000
(20 rows)
SELECT depname, empno, salary, sum(salary) OVER w FROM empsalary WINDOW w AS (PARTITION BY depname);
***************
*** 411,428 ****
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER (PARTITION BY two ORDER BY ten) AS wsum
FROM tenk1 GROUP BY ten, two;
! ten | two | gsum | wsum
! -----+-----+-------+--------
! 0 | 0 | 45000 | 45000
! 2 | 0 | 47000 | 92000
! 4 | 0 | 49000 | 141000
! 6 | 0 | 51000 | 192000
! 8 | 0 | 53000 | 245000
! 1 | 1 | 46000 | 46000
! 3 | 1 | 48000 | 94000
! 5 | 1 | 50000 | 144000
! 7 | 1 | 52000 | 196000
! 9 | 1 | 54000 | 250000
(10 rows)
SELECT count(*) OVER (PARTITION BY four), four FROM (SELECT * FROM tenk1 WHERE two = 1)s WHERE unique2 < 10;
--- 411,428 ----
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER (PARTITION BY two ORDER BY ten) AS wsum
FROM tenk1 GROUP BY ten, two;
! ten | two | gsum | wsum
! -----+-----+-------+--------------------------------
! 0 | 0 | 45000 | 0
! 2 | 0 | 47000 | 79507201984648764290546794496
! 4 | 0 | 49000 | 159014403969297528581093588992
! 6 | 0 | 51000 | 238521605953946292871640383488
! 8 | 0 | 53000 | 318028807938595057162187177984
! 1 | 1 | 46000 | 0
! 3 | 1 | 48000 | 79507201984648764290546794496
! 5 | 1 | 50000 | 159014403969297528581093588992
! 7 | 1 | 52000 | 238521605953946292871640383488
! 9 | 1 | 54000 | 318028807938595057162187177984
(10 rows)
SELECT count(*) OVER (PARTITION BY four), four FROM (SELECT * FROM tenk1 WHERE two = 1)s WHERE unique2 < 10;
***************
*** 483,500 ****
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER win AS wsum
FROM tenk1 GROUP BY ten, two WINDOW win AS (PARTITION BY two ORDER BY ten);
! ten | two | gsum | wsum
! -----+-----+-------+--------
! 0 | 0 | 45000 | 45000
! 2 | 0 | 47000 | 92000
! 4 | 0 | 49000 | 141000
! 6 | 0 | 51000 | 192000
! 8 | 0 | 53000 | 245000
! 1 | 1 | 46000 | 46000
! 3 | 1 | 48000 | 94000
! 5 | 1 | 50000 | 144000
! 7 | 1 | 52000 | 196000
! 9 | 1 | 54000 | 250000
(10 rows)
-- more than one window with GROUP BY
--- 483,500 ----
SELECT ten, two, sum(hundred) AS gsum, sum(sum(hundred)) OVER win AS wsum
FROM tenk1 GROUP BY ten, two WINDOW win AS (PARTITION BY two ORDER BY ten);
! ten | two | gsum | wsum
! -----+-----+-------+--------------------------------
! 0 | 0 | 45000 | 0
! 2 | 0 | 47000 | 79507201984648764290546794496
! 4 | 0 | 49000 | 159014403969297528581093588992
! 6 | 0 | 51000 | 238521605953946292871640383488
! 8 | 0 | 53000 | 318028807938595057162187177984
! 1 | 1 | 46000 | 0
! 3 | 1 | 48000 | 79507201984648764290546794496
! 5 | 1 | 50000 | 159014403969297528581093588992
! 7 | 1 | 52000 | 238521605953946292871640383488
! 9 | 1 | 54000 | 318028807938595057162187177984
(10 rows)
-- more than one window with GROUP BY
***************
*** 502,512 ****
row_number() OVER (ORDER BY depname),
sum(sum(salary)) OVER (ORDER BY depname DESC)
FROM empsalary GROUP BY depname;
! sum | row_number | sum
! -------+------------+-------
! 14600 | 3 | 14600
! 7400 | 2 | 22000
! 25100 | 1 | 47100
(3 rows)
-- identical windows with different names
--- 502,512 ----
row_number() OVER (ORDER BY depname),
sum(sum(salary)) OVER (ORDER BY depname DESC)
FROM empsalary GROUP BY depname;
! sum | row_number | sum
! -------+------------+--------------------------------
! 14600 | 3 | 0
! 7400 | 2 | 79507201984648764290546794496
! 25100 | 1 | 159014403969297528581093588992
(3 rows)
-- identical windows with different names
***************
*** 1027,1037 ****
) FILTER (WHERE depname <> 'sales') OVER (ORDER BY depname DESC) AS "filtered_sum",
depname
FROM empsalary GROUP BY depname;
! sum | row_number | filtered_sum | depname
! -------+------------+--------------+-----------
! 14600 | 3 | | sales
! 7400 | 2 | 3500 | personnel
! 25100 | 1 | 22600 | develop
(3 rows)
-- Test pushdown of quals into a subquery containing window functions
--- 1027,1037 ----
) FILTER (WHERE depname <> 'sales') OVER (ORDER BY depname DESC) AS "filtered_sum",
depname
FROM empsalary GROUP BY depname;
! sum | row_number | filtered_sum | depname
! -------+------------+-------------------------------+-----------
! 14600 | 3 | | sales
! 7400 | 2 | 0 | personnel
! 25100 | 1 | 79507201984648764290546794496 | develop
(3 rows)
-- Test pushdown of quals into a subquery containing window functions
***************
*** 1341,1352 ****
-- test inverse transition functions handle NULLs properly
SELECT i,AVG(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | avg
! ---+--------------------
! 1 | 1.5000000000000000
! 2 | 2.0000000000000000
! 3 |
! 4 |
(4 rows)
SELECT i,AVG(v::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1341,1352 ----
-- test inverse transition functions handle NULLs properly
SELECT i,AVG(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | avg
! ---+-------------------------------
! 1 | 39753600992324382145273397248
! 2 | 0.00000000000000000000
! 3 |
! 4 |
(4 rows)
SELECT i,AVG(v::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1411,1422 ****
SELECT i,SUM(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | sum
! ---+-----
! 1 | 3
! 2 | 2
! 3 |
! 4 |
(4 rows)
SELECT i,SUM(v::money) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1411,1422 ----
SELECT i,SUM(v::bigint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,1),(2,2),(3,NULL),(4,NULL)) t(i,v);
! i | sum
! ---+-------------------------------
! 1 | 79507201984648764290546794496
! 2 | 0
! 3 |
! 4 |
(4 rows)
SELECT i,SUM(v::money) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1491,1514 ****
SELECT VAR_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! -----------------------
! 21704.000000000000
! 13868.750000000000
! 11266.666666666667
! 4225.0000000000000000
! 0
(5 rows)
SELECT VAR_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! -----------------------
! 21704.000000000000
! 13868.750000000000
! 11266.666666666667
! 4225.0000000000000000
! 0
(5 rows)
SELECT VAR_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1491,1514 ----
SELECT VAR_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! ---------
! 0
! 0
! 0
! 0
! 0
(5 rows)
SELECT VAR_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_pop
! ---------
! 0
! 0
! 0
! 0
! 0
(5 rows)
SELECT VAR_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1535,1558 ****
SELECT VAR_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VAR_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VAR_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1535,1558 ----
SELECT VAR_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VAR_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! var_samp
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VAR_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1579,1602 ****
SELECT VARIANCE(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VARIANCE(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! -----------------------
! 27130.000000000000
! 18491.666666666667
! 16900.000000000000
! 8450.0000000000000000
!
(5 rows)
SELECT VARIANCE(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1579,1602 ----
SELECT VARIANCE(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VARIANCE(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! variance
! ----------
! 0
! 0
! 0
! 0
!
(5 rows)
SELECT VARIANCE(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1624,1649 ****
SELECT STDDEV_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ---------------------
! 147.322774885623
! 147.322774885623
! 117.765657133139
! 106.144555520604
! 65.0000000000000000
! 0
(6 rows)
SELECT STDDEV_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ---------------------
! 147.322774885623
! 147.322774885623
! 117.765657133139
! 106.144555520604
! 65.0000000000000000
! 0
(6 rows)
SELECT STDDEV_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1624,1649 ----
SELECT STDDEV_POP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ------------
! 0
! 0
! 0
! 0
! 0
! 0
(6 rows)
SELECT STDDEV_POP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_pop
! ------------
! 0
! 0
! 0
! 0
! 0
! 0
(6 rows)
SELECT STDDEV_POP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1672,1697 ****
SELECT STDDEV_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1672,1697 ----
SELECT STDDEV_SAMP(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! -------------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV_SAMP(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(1,NULL),(2,600),(3,470),(4,170),(5,430),(6,300)) r(i,n);
! stddev_samp
! -------------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV_SAMP(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
***************
*** 1720,1745 ****
SELECT STDDEV(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! ---------------------
! 164.711869639076
! 164.711869639076
! 135.984067694222
! 130.000000000000
! 91.9238815542511782
!
(6 rows)
SELECT STDDEV(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
--- 1720,1745 ----
SELECT STDDEV(n::int) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! --------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV(n::smallint) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
FROM (VALUES(0,NULL),(1,600),(2,470),(3,170),(4,430),(5,300)) r(i,n);
! stddev
! --------
! 0
! 0
! 0
! 0
! 0
!
(6 rows)
SELECT STDDEV(n::numeric) OVER (ORDER BY i ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/with.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/with.out Fri Jan 12 12:39:31 2018
***************
*** 285,291 ****
SELECT count(*) FROM q1 WHERE y > (SELECT sum(y)/100 FROM q1 qsub);
count
-------
! 50
(1 row)
-- via a VIEW
--- 285,291 ----
SELECT count(*) FROM q1 WHERE y > (SELECT sum(y)/100 FROM q1 qsub);
count
-------
! 0
(1 row)
-- via a VIEW
======================================================================
*** /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/expected/stats.out Thu Jan 11 19:37:51 2018
--- /home/buildfarm/mpolyakova/postgresql_master/src/test/regress/results/stats.out Fri Jan 12 12:39:58 2018
***************
*** 25,30 ****
--- 25,31 ----
FROM pg_catalog.pg_stat_user_tables AS t,
pg_catalog.pg_statio_user_tables AS b
WHERE t.relname='tenk2' AND b.relname='tenk2';
+ ERROR: bigint out of range
-- function to wait for counters to advance
create function wait_for_stats() returns void as $$
declare
***************
*** 154,164 ****
\c -
-- wait for stats collector to update
SELECT wait_for_stats();
! wait_for_stats
! ----------------
!
! (1 row)
!
-- check effects
SELECT relname, n_tup_ins, n_tup_upd, n_tup_del, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
--- 155,166 ----
\c -
-- wait for stats collector to update
SELECT wait_for_stats();
! ERROR: relation "prevstats" does not exist
! LINE 1: ... FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats ...
! ^
! QUERY: SELECT (st.seq_scan >= pr.seq_scan + 1) FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
! WHERE st.relname='tenk2' AND cl.relname='tenk2'
! CONTEXT: PL/pgSQL function wait_for_stats() line 18 at SQL statement
-- check effects
SELECT relname, n_tup_ins, n_tup_upd, n_tup_del, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
***************
*** 165,175 ****
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
! trunc_stats_test | 3 | 0 | 0 | 0 | 0
! trunc_stats_test1 | 4 | 2 | 1 | 1 | 0
! trunc_stats_test2 | 1 | 0 | 0 | 1 | 0
! trunc_stats_test3 | 4 | 0 | 0 | 2 | 2
! trunc_stats_test4 | 2 | 0 | 0 | 0 | 2
(5 rows)
SELECT st.seq_scan >= pr.seq_scan + 1,
--- 167,177 ----
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
! trunc_stats_test | 0 | 0 | 0 | 0 | 0
! trunc_stats_test1 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test2 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test3 | 0 | 0 | 0 | 0 | 0
! trunc_stats_test4 | 0 | 0 | 0 | 0 | 0
(5 rows)
SELECT st.seq_scan >= pr.seq_scan + 1,
***************
*** 178,204 ****
st.idx_tup_fetch >= pr.idx_tup_fetch + 1
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ?column? | ?column? | ?column? | ?column?
! ----------+----------+----------+----------
! t | t | t | t
! (1 row)
!
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1
FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ?column? | ?column?
! ----------+----------
! t | t
! (1 row)
!
SELECT pr.snap_ts < pg_stat_get_snapshot_timestamp() as snapshot_newer
FROM prevstats AS pr;
! snapshot_newer
! ----------------
! t
! (1 row)
!
DROP TABLE trunc_stats_test, trunc_stats_test1, trunc_stats_test2, trunc_stats_test3, trunc_stats_test4;
DROP TABLE prevstats;
-- End of Stats Test
--- 180,201 ----
st.idx_tup_fetch >= pr.idx_tup_fetch + 1
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ERROR: relation "prevstats" does not exist
! LINE 5: FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats ...
! ^
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1
FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
! ERROR: relation "prevstats" does not exist
! LINE 3: ...FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats ...
! ^
SELECT pr.snap_ts < pg_stat_get_snapshot_timestamp() as snapshot_newer
FROM prevstats AS pr;
! ERROR: relation "prevstats" does not exist
! LINE 2: FROM prevstats AS pr;
! ^
DROP TABLE trunc_stats_test, trunc_stats_test1, trunc_stats_test2, trunc_stats_test3, trunc_stats_test4;
DROP TABLE prevstats;
+ ERROR: table "prevstats" does not exist
-- End of Stats Test
======================================================================
272c2ab_regression.out (text/plain, 8.7K) download
test tablespace ... ok
parallel group (20 tests): int4 text boolean name varchar char float4 int8 oid int2 pg_lsn regproc float8 txid uuid money bit enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
pg_lsn ... ok
regproc ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): timestamptz tinterval interval reltime abstime timestamp date circle timetz time point path line lseg macaddr box macaddr8 inet tstypes polygon
point ... ok
lseg ... ok
line ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
macaddr8 ... ok
tstypes ... ok
parallel group (9 tests): geometry comments expressions horology misc_sanity type_sanity oidjoins opr_sanity regex
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
misc_sanity ... ok
comments ... ok
expressions ... ok
test insert ... ok
test insert_conflict ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (3 tests): copydml copyselect copy
copy ... ok
copyselect ... ok
copydml ... ok
parallel group (3 tests): create_operator create_procedure create_misc
create_misc ... ok
create_operator ... ok
create_procedure ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (15 tests): create_function_3 create_aggregate create_cast drop_if_exists roleattributes hash_func typed_table create_am constraints rolenames vacuum create_table_like inherit updatable_views triggers
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
rolenames ... ok
roleattributes ... ok
create_am ... ok
hash_func ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): btree_index select_into random case select_implicit select_having select_distinct select_distinct_on namespace delete transactions portals prepared_xacts subselect union update arrays aggregates hash_index join
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 ... ok
transactions ... ok
random ... failed (ignored)
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (17 tests): lock security_label init_privs drop_operator password tablesample replica_identity groupingsets object_address collate matview privileges brin spgist gin rowsecurity gist
brin ... ok
gin ... ok
gist ... ok
spgist ... ok
privileges ... ok
init_privs ... ok
security_label ... ok
collate ... ok
matview ... ok
lock ... ok
replica_identity ... ok
rowsecurity ... ok
object_address ... ok
tablesample ... ok
groupingsets ... FAILED
drop_operator ... ok
password ... ok
parallel group (11 tests): alter_operator async dbsize misc_functions psql tidscan alter_generic tsrf sysviews misc stats_ext
alter_generic ... ok
alter_operator ... ok
misc ... ok
psql ... ok
async ... ok
dbsize ... ok
misc_functions ... ok
sysviews ... ok
tsrf ... FAILED
tidscan ... ok
stats_ext ... ok
parallel group (3 tests): amutils psql_crosstab rules
rules ... ok
psql_crosstab ... ok
amutils ... ok
test select_parallel ... FAILED
test write_parallel ... ok
parallel group (2 tests): subscription publication
publication ... ok
subscription ... ok
parallel group (20 tests): json_encoding advisory_lock tsdicts dependency combocid guc portals_p2 select_views xmlmap window functional_deps equivclass tsearch json cluster jsonb bitmapops indirect_toast foreign_key foreign_data
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... FAILED
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
jsonb ... ok
json_encoding ... ok
indirect_toast ... ok
equivclass ... ok
parallel group (19 tests): conversion plancache prepare limit temp copy2 returning without_oid rowtypes truncate polymorphism sequence with rangefuncs largeobject domain xml alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... FAILED
xml ... ok
parallel group (5 tests): reloptions hash_part identity partition_prune partition_join
identity ... ok
partition_join ... ok
partition_prune ... ok
reloptions ... ok
hash_part ... ok
test event_trigger ... ok
test stats ... FAILED
* Re: master make check fails on Solaris 10
@ 2018-01-12 15:12 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
1 sibling, 1 reply; 46+ messages in thread
From: Alvaro Herrera @ 2018-01-12 15:12 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers
Marina Polyakova wrote:
> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) the same
> failures occur (see the attached regression diffs and output);
> - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
> passes.
> I'll try to find out from what commit it started.. Don't you have any
> suspicions?)
Perhaps you can use "git bisect".
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-12 15:15 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 0 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-12 15:15 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers
On 12-01-2018 18:12, Alvaro Herrera wrote:
> Marina Polyakova wrote:
>
>> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
>> the same
>> failures occur (see the attached regression diffs and output);
>> - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
>> passes.
>> I'll try to find out from what commit it started.. Don't you have any
>> suspicions?)
>
> Perhaps you can use "git bisect".
Thanks, I'm doing the same thing :)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-12 17:50 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
1 sibling, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-12 17:50 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>; Alvaro Herrera <alvherre@alvh.no-ip.org>
On 12-01-2018 14:05, Marina Polyakova wrote:
> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
> the same failures occur (see the attached regression diffs and
> output);
> - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
> passes.
> I'll try to find out from what commit it started..
Binary search has shown that all these failures begin with commit
7518049980be1d90264addab003476ae105f70d4 (Prevent int128 from requiring
more than MAXALIGN alignment.). On the previous commit
(91aec93e6089a5ba49cce0aca3bf7f7022d62ea4) make check-world passes.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-12 18:00 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-12 18:00 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 12-01-2018 14:05, Marina Polyakova wrote:
>> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
>> the same failures occur (see the attached regression diffs and
>> output);
>> - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
>> passes.
>> I'll try to find out from what commit it started..
> Binary search has shown that all these failures begin with commit
> 7518049980be1d90264addab003476ae105f70d4 (Prevent int128 from requiring
> more than MAXALIGN alignment.).
Hm ... so apparently, that compiler has bugs in handling nondefault
alignment specs. You said upthread it was gcc, but what version
exactly?
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-13 09:40 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-13 09:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 12-01-2018 21:00, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> ...
>> Binary search has shown that all these failures begin with commit
>> 7518049980be1d90264addab003476ae105f70d4 (Prevent int128 from
>> requiring
>> more than MAXALIGN alignment.).
>
> Hm ... so apparently, that compiler has bugs in handling nondefault
> alignment specs. You said upthread it was gcc, but what version
> exactly?
This is 5.2.0:
$ gcc -v
Reading specs from /opt/csw/lib/gcc/sparc-sun-solaris2.10/5.2.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/sparc-sun-solaris2.10/5.2.0/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with:
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.2.0/configure
--prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin
--sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec
--datadir=/opt/csw/share --sysconfdir=/etc/opt/csw
--sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw
--libdir=/opt/csw/lib --infodir=/opt/csw/share/info
--includedir=/opt/csw/include --mandir=/opt/csw/share/man
--enable-cloog-backend=isl --enable-java-awt=xlib
--enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada
--enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix
--program-suffix=-5.2 --with-cloog=/opt/csw --with-gmp=/opt/csw
--with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw
--with-system-zlib=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-as
Thread model: posix
gcc version 5.2.0 (GCC)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-13 18:10 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-13 18:10 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 12-01-2018 21:00, Tom Lane wrote:
>> Hm ... so apparently, that compiler has bugs in handling nondefault
>> alignment specs. You said upthread it was gcc, but what version
>> exactly?
> This is 5.2.0:
Ugh ... protosciurus has 3.4.3, but I see that configure detects that
as *not* having __int128. Probably what's happening on your machine
is that gcc knows __int128 but generates buggy code for it when an
alignment spec is given. So that's unfortunate, but it's not really
a regression from 3.4.3.
I'm not sure there's much we can do about this. Dropping the use
of the alignment spec isn't a workable option. If there were a
simple way for configure to detect that the compiler generates bad
code for that, we could have it do so and reject use of __int128,
but it'd be up to you to come up with a workable test.
In the end this might just be an instance of the old saw about
avoiding dot-zero releases. Have you tried a newer gcc?
(Digging in their bugzilla finds quite a number of __int128 bugs
fixed in 5.4.x, though none look to be specifically about
misaligned data.)
Also, if it still happens with current gcc on that hardware,
there'd be grounds for a new bug report to them.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-15 12:07 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-15 12:07 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Thank you very much!
On 13-01-2018 21:10, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 12-01-2018 21:00, Tom Lane wrote:
>>> Hm ... so apparently, that compiler has bugs in handling nondefault
>>> alignment specs. You said upthread it was gcc, but what version
>>> exactly?
>
>> This is 5.2.0:
>
> Ugh ... protosciurus has 3.4.3, but I see that configure detects that
> as *not* having __int128. Probably what's happening on your machine
> is that gcc knows __int128 but generates buggy code for it when an
> alignment spec is given. So that's unfortunate, but it's not really
> a regression from 3.4.3.
>
> I'm not sure there's much we can do about this. Dropping the use
> of the alignment spec isn't a workable option. If there were a
> simple way for configure to detect that the compiler generates bad
> code for that, we could have it do so and reject use of __int128,
> but it'd be up to you to come up with a workable test.
I'll think about it..
> In the end this might just be an instance of the old saw about
> avoiding dot-zero releases. Have you tried a newer gcc?
> (Digging in their bugzilla finds quite a number of __int128 bugs
> fixed in 5.4.x, though none look to be specifically about
> misaligned data.)
As I was told offlist, 5.2.0 is already a fairly new version of gcc for
this system..
> Also, if it still happens with current gcc on that hardware,
> there'd be grounds for a new bug report to them.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-15 23:41 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-15 23:41 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 13-01-2018 21:10, Tom Lane wrote:
>> I'm not sure there's much we can do about this. Dropping the use
>> of the alignment spec isn't a workable option. If there were a
>> simple way for configure to detect that the compiler generates bad
>> code for that, we could have it do so and reject use of __int128,
>> but it'd be up to you to come up with a workable test.
> I'll think about it..
Attached is a possible test program. I can confirm it passes on a
machine with working __int128, but I have no idea whether it will
detect the problem on yours. If not, maybe you can tweak it?
regards, tom lane
Attachments:
int128test.c (text/x-c, 1.1K) download
#include <stddef.h>
#include <stdio.h>
/* GCC, Sunpro and XLC support aligned */
#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#endif
typedef __int128 int128a
#if defined(pg_attribute_aligned)
pg_attribute_aligned(8)
#endif
;
/*
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants. We do not have
* convenient support for 128bit literals at this point...
*/
struct glob128
{
__int128 start;
char pad;
int128a a;
int128a b;
int128a c;
int128a d;
} g = {0, 'p', 48828125, 97656255, 0, 0};
int
main()
{
if (offsetof(struct glob128, a) < 17 ||
offsetof(struct glob128, a) > 24)
{
printf("wrong alignment, %d\n", (int) offsetof(struct glob128, a));
return 1;
}
g.a = (g.a << 12) + 1; /* 200000000001 */
g.b = (g.b << 12) + 5; /* 400000000005 */
/* use the most relevant arithmetic ops */
g.c = g.a * g.b;
g.d = (g.c + g.b) / g.b;
/* return different values, to prevent optimizations */
if (g.d != g.a + 1)
{
printf("wrong arithmetic result\n");
return 1;
}
printf("A-OK!\n");
return 0;
}
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:02 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 4 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-17 15:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
[I added Victor Wagner as co-researcher of this problem]
On 13-01-2018 21:10, Tom Lane wrote:
> In the end this might just be an instance of the old saw about
> avoiding dot-zero releases. Have you tried a newer gcc?
> (Digging in their bugzilla finds quite a number of __int128 bugs
> fixed in 5.4.x, though none look to be specifically about
> misaligned data.)
gcc 5.5.0 (from [1]) did not fix the problem..
On 16-01-2018 2:41, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 13-01-2018 21:10, Tom Lane wrote:
>>> I'm not sure there's much we can do about this. Dropping the use
>>> of the alignment spec isn't a workable option. If there were a
>>> simple way for configure to detect that the compiler generates bad
>>> code for that, we could have it do so and reject use of __int128,
>>> but it'd be up to you to come up with a workable test.
>
>> I'll think about it..
>
> Attached is a possible test program. I can confirm it passes on a
> machine with working __int128, but I have no idea whether it will
> detect the problem on yours. If not, maybe you can tweak it?
Thank you! Using gcc 5.5.0 it prints that everything is ok. But,
investigating the regression diffs, we found out that the error occurs
when we pass int128 as not the first argument to the function (perhaps
its value is replaced by the value of some address):
-- Use queries from random.sql
SELECT count(*) FROM onek; -- Everything is ok
...
SELECT random, count(random) FROM RANDOM_TBL
GROUP BY random HAVING count(random) > 3; -- Everything is ok
postgres=# SELECT * FROM RANDOM_TBL ORDER BY random; -- Print current
data
random
--------
78
86
98
98
(4 rows)
postgres=# SELECT AVG(random) FROM RANDOM_TBL
postgres-# HAVING AVG(random) NOT BETWEEN 80 AND 120; -- Oops!
avg
-------------------------------
79446934848446476698976780288
(1 row)
Debug output from the last query (see attached diff.patch, it is based
on commit 9c7d06d60680c7f00d931233873dee81fdb311c6 of master):
makeInt128AggState
int8_avg_accum val 98
int8_avg_accum val_int128 as 2 x int64: 0 98
int8_avg_accum val_int128 bytes: 00000000000000000000000000000062
int8_avg_accum state 100e648d8
int8_avg_accum 1007f2e94
do_int128_accum int128 newval as 2 x int64: 4306826968 0
do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
do_int128_accum state 100e648d8
do_int128_accum 1007f1e30
int8_avg_accum val 86
int8_avg_accum val_int128 as 2 x int64: 0 86
int8_avg_accum val_int128 bytes: 00000000000000000000000000000056
int8_avg_accum state 100e648d8
int8_avg_accum 1007f2e94
do_int128_accum int128 newval as 2 x int64: 4306826968 0
do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
do_int128_accum state 100e648d8
do_int128_accum 1007f1e30
int8_avg_accum val 98
int8_avg_accum val_int128 as 2 x int64: 0 98
int8_avg_accum val_int128 bytes: 00000000000000000000000000000062
int8_avg_accum state 100e648d8
int8_avg_accum 1007f2e94
do_int128_accum int128 newval as 2 x int64: 4306826968 0
do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
do_int128_accum state 100e648d8
do_int128_accum 1007f1e30
int8_avg_accum val 78
int8_avg_accum val_int128 as 2 x int64: 0 78
int8_avg_accum val_int128 bytes: 0000000000000000000000000000004E
int8_avg_accum state 100e648d8
int8_avg_accum 1007f2e94
do_int128_accum int128 newval as 2 x int64: 4306826968 0
do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
do_int128_accum state 100e648d8
do_int128_accum 1007f1e30
numeric_poly_avg
int128_to_numericvar
int128_to_numericvar int128 val as 2 x int64: 17227307872 0
int128_to_numericvar int128 val bytes: 0000000402D3DB600000000000000000
(val_int128 in the function int8_avg_accum is correct, but newval in the
function do_int128_accum is not equal to it. val in the function
int128_to_numericvar is (4 * 4306826968).)
Based on this, we modified the test program (see attached). Here is its
output on Solaris 10 for different alignments requirements for int128
(on my machine where make check-world passes everything is OK)
(ALIGNOF_PG_INT128_TYPE is 16 on Solaris 10):
$ gcc -D PG_ALIGN_128=16 -m64 -o int128test2 int128test2.c
$ ./int128test2
basic aritmetic OK
pass int 16 OK
pass uint 16 OK
pass int 32 OK
pass int 64 OK
pass int 128 OK
$ gcc -D PG_ALIGN_128=8 -m64 -o int128test2 int128test2.c
$ ./int128test2
basic aritmetic OK
pass int 16 FAILED
pass uint 16 FAILED
pass int 32 FAILED
pass int 64 FAILED
pass int 128 OK
Maybe some pass test from int128test2.c can be used to test __int128?
P.S. I suppose, g.b should be 97656250 to get 400000000005:
> struct glob128
> {
> __int128 start;
> char pad;
> int128a a;
> int128a b;
> int128a c;
> int128a d;
> } g = {0, 'p', 48828125, 97656255, 0, 0};
> ...
> g.b = (g.b << 12) + 5; /* 400000000005 */
[1] https://www.opencsw.org
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
int128test2.c (text/x-c, 2.2K) download
#include <stddef.h>
#include <stdio.h>
#ifndef PG_ALIGN_128
#define PG_ALIGN_128 8
#endif
/* GCC, Sunpro and XLC support aligned */
#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#endif
typedef __int128 int128a
#if defined(pg_attribute_aligned)
pg_attribute_aligned(PG_ALIGN_128)
#endif
;
/*
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants. We do not have
* convenient support for 128bit literals at this point...
*/
struct glob128
{
__int128 start;
char pad;
int128a a;
int128a b;
int128a c;
int128a d;
} g = {0, 'p', 48828125, 97656250, 0, 0};
int128a holder;
void pass_by_val(char *buffer, int128a par) {
holder = par;
}
int
main()
{
char *message = "Everything is fine";
short int i16 = 31000;
unsigned short int u16 = 49000;
int i32 = 48828125;
long int i64 = 97656225L << 12;
int128a q;
int failures = 0;
/* Basic arithmetic tests */
g.a = (g.a << 12) + 1; /* 200000000001 */
g.b = (g.b << 12) + 5; /* 400000000005 */
/* use the most relevant arithmetic ops */
g.c = g.a * g.b;
g.d = (g.c + g.b) / g.b;
/* return different values, to prevent optimizations */
if (g.d != g.a + 1)
{
printf("wrong arithmetic result\n");
failures++;
}
else
{
printf("basic aritmetic OK\n");
}
pass_by_val(message, (int128a) i16);
q = (int128a) i16;
printf("pass int 16 %s\n", (q == holder) ? "OK" : "FAILED");
if (q != holder)
failures++;
pass_by_val(message, (int128a) u16);
q = (int128a) u16;
printf("pass uint 16 %s\n", (q == holder) ? "OK" : "FAILED");
if (q != holder)
failures++;
pass_by_val(message, (int128a) i32);
q = (int128a) i32;
printf("pass int 32 %s\n", (q == holder) ? "OK" : "FAILED");
if (q != holder)
failures++;
pass_by_val(message, (int128a) i64);
q = (int128a) i64;
printf("pass int 64 %s\n", (q == holder) ? "OK" : "FAILED");
if (q != holder)
failures++;
q = (int128a) (i64 << 33);
pass_by_val(message, q);
printf("pass int 128 %s\n", (q == holder) ? "OK" : "FAILED");
if (q != holder)
failures++;
return failures;
}
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:07 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
3 siblings, 2 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-17 15:07 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> investigating the regression diffs, we found out that the error occurs
> when we pass int128 as not the first argument to the function (perhaps
> its value is replaced by the value of some address):
> ...
> Based on this, we modified the test program (see attached). Here is its
> output on Solaris 10 for different alignments requirements for int128
> (on my machine where make check-world passes everything is OK)
> (ALIGNOF_PG_INT128_TYPE is 16 on Solaris 10):
Excellent. This fails the same way on gcc 5.2.0 and 5.5.0?
> Maybe some pass test from int128test2.c can be used to test __int128?
Yeah, I can work with this. What I propose to do is use a somewhat
stripped-down version of this test as an AC_RUN_IFELSE test normally,
but if cross-compiling, fall back to just seeing if we can link.
Thanks for investigating!
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:12 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
3 siblings, 0 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-17 15:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Sorry, diff.patch is attached now.
On 17-01-2018 18:02, Marina Polyakova wrote:
> [I added Victor Wagner as co-researcher of this problem]
>
> On 13-01-2018 21:10, Tom Lane wrote:
>> In the end this might just be an instance of the old saw about
>> avoiding dot-zero releases. Have you tried a newer gcc?
>> (Digging in their bugzilla finds quite a number of __int128 bugs
>> fixed in 5.4.x, though none look to be specifically about
>> misaligned data.)
>
> gcc 5.5.0 (from [1]) did not fix the problem..
>
> On 16-01-2018 2:41, Tom Lane wrote:
>> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>>> On 13-01-2018 21:10, Tom Lane wrote:
>>>> I'm not sure there's much we can do about this. Dropping the use
>>>> of the alignment spec isn't a workable option. If there were a
>>>> simple way for configure to detect that the compiler generates bad
>>>> code for that, we could have it do so and reject use of __int128,
>>>> but it'd be up to you to come up with a workable test.
>>
>>> I'll think about it..
>>
>> Attached is a possible test program. I can confirm it passes on a
>> machine with working __int128, but I have no idea whether it will
>> detect the problem on yours. If not, maybe you can tweak it?
>
> Thank you! Using gcc 5.5.0 it prints that everything is ok. But,
> investigating the regression diffs, we found out that the error occurs
> when we pass int128 as not the first argument to the function (perhaps
> its value is replaced by the value of some address):
>
> -- Use queries from random.sql
> SELECT count(*) FROM onek; -- Everything is ok
> ...
> SELECT random, count(random) FROM RANDOM_TBL
> GROUP BY random HAVING count(random) > 3; -- Everything is ok
>
> postgres=# SELECT * FROM RANDOM_TBL ORDER BY random; -- Print current
> data
> random
> --------
> 78
> 86
> 98
> 98
> (4 rows)
>
> postgres=# SELECT AVG(random) FROM RANDOM_TBL
> postgres-# HAVING AVG(random) NOT BETWEEN 80 AND 120; -- Oops!
> avg
> -------------------------------
> 79446934848446476698976780288
> (1 row)
>
> Debug output from the last query (see attached diff.patch, it is based
> on commit 9c7d06d60680c7f00d931233873dee81fdb311c6 of master):
>
> makeInt128AggState
> int8_avg_accum val 98
> int8_avg_accum val_int128 as 2 x int64: 0 98
> int8_avg_accum val_int128 bytes: 00000000000000000000000000000062
> int8_avg_accum state 100e648d8
> int8_avg_accum 1007f2e94
> do_int128_accum int128 newval as 2 x int64: 4306826968 0
> do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
> do_int128_accum state 100e648d8
> do_int128_accum 1007f1e30
> int8_avg_accum val 86
> int8_avg_accum val_int128 as 2 x int64: 0 86
> int8_avg_accum val_int128 bytes: 00000000000000000000000000000056
> int8_avg_accum state 100e648d8
> int8_avg_accum 1007f2e94
> do_int128_accum int128 newval as 2 x int64: 4306826968 0
> do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
> do_int128_accum state 100e648d8
> do_int128_accum 1007f1e30
> int8_avg_accum val 98
> int8_avg_accum val_int128 as 2 x int64: 0 98
> int8_avg_accum val_int128 bytes: 00000000000000000000000000000062
> int8_avg_accum state 100e648d8
> int8_avg_accum 1007f2e94
> do_int128_accum int128 newval as 2 x int64: 4306826968 0
> do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
> do_int128_accum state 100e648d8
> do_int128_accum 1007f1e30
> int8_avg_accum val 78
> int8_avg_accum val_int128 as 2 x int64: 0 78
> int8_avg_accum val_int128 bytes: 0000000000000000000000000000004E
> int8_avg_accum state 100e648d8
> int8_avg_accum 1007f2e94
> do_int128_accum int128 newval as 2 x int64: 4306826968 0
> do_int128_accum int128 newval bytes: 0000000100B4F6D80000000000000000
> do_int128_accum state 100e648d8
> do_int128_accum 1007f1e30
> numeric_poly_avg
> int128_to_numericvar
> int128_to_numericvar int128 val as 2 x int64: 17227307872 0
> int128_to_numericvar int128 val bytes: 0000000402D3DB600000000000000000
>
> (val_int128 in the function int8_avg_accum is correct, but newval in
> the function do_int128_accum is not equal to it. val in the function
> int128_to_numericvar is (4 * 4306826968).)
>
> Based on this, we modified the test program (see attached). Here is
> its output on Solaris 10 for different alignments requirements for
> int128 (on my machine where make check-world passes everything is OK)
> (ALIGNOF_PG_INT128_TYPE is 16 on Solaris 10):
>
> $ gcc -D PG_ALIGN_128=16 -m64 -o int128test2 int128test2.c
> $ ./int128test2
> basic aritmetic OK
> pass int 16 OK
> pass uint 16 OK
> pass int 32 OK
> pass int 64 OK
> pass int 128 OK
> $ gcc -D PG_ALIGN_128=8 -m64 -o int128test2 int128test2.c
> $ ./int128test2
> basic aritmetic OK
> pass int 16 FAILED
> pass uint 16 FAILED
> pass int 32 FAILED
> pass int 64 FAILED
> pass int 128 OK
>
> Maybe some pass test from int128test2.c can be used to test __int128?
>
> P.S. I suppose, g.b should be 97656250 to get 400000000005:
>
>> struct glob128
>> {
>> __int128 start;
>> char pad;
>> int128a a;
>> int128a b;
>> int128a c;
>> int128a d;
>> } g = {0, 'p', 48828125, 97656255, 0, 0};
>> ...
>> g.b = (g.b << 12) + 5; /* 400000000005 */
>
> [1] https://www.opencsw.org
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
diff.patch (text/x-diff, 2.9K) download
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
index 5b34bad..64d131f 100644
--- a/src/backend/utils/adt/numeric.c
+++ b/src/backend/utils/adt/numeric.c
@@ -3953,6 +3953,8 @@ makeInt128AggState(FunctionCallInfo fcinfo, bool calcSumX2)
MemoryContext agg_context;
MemoryContext old_context;
+ fprintf(stderr, "makeInt128AggState\n");
+
if (!AggCheckCallContext(fcinfo, &agg_context))
elog(ERROR, "aggregate function called in non-aggregate context");
@@ -3987,6 +3989,18 @@ makeInt128AggStateCurrentContext(bool calcSumX2)
static void
do_int128_accum(Int128AggState *state, int128 newval)
{
+ fprintf(stderr, "do_int128_accum int128 newval as 2 x int64: %ld %ld\n",
+ (int64) (newval >> 64), (int64) newval);
+
+ fprintf(stderr, "do_int128_accum int128 newval bytes: ");
+ unsigned char* byte_array = (void *) &newval;
+ for (int index = 0; index < 16; ++index)
+ fprintf(stderr, "%02X", (unsigned)byte_array[index]);
+ fprintf(stderr, "\n");
+
+ fprintf(stderr, "do_int128_accum state %p\n", state);
+ fprintf(stderr, "do_int128_accum %p\n", &do_int128_accum);
+
if (state->calcSumX2)
state->sumX2 += newval * newval;
@@ -4307,10 +4321,27 @@ int8_avg_accum(PG_FUNCTION_ARGS)
if (state == NULL)
state = makePolyNumAggState(fcinfo, false);
+ int64 val = PG_GETARG_INT64(1);
+ fprintf(stderr, "int8_avg_accum val %ld\n", val);
+
+ int128 val_int128 = (int128) val;
+
+ fprintf(stderr, "int8_avg_accum val_int128 as 2 x int64: %ld %ld\n",
+ (int64) (val_int128 >> 64), (int64) val_int128);
+
+ fprintf(stderr, "int8_avg_accum val_int128 bytes: ");
+ unsigned char* byte_array = (void *) &val_int128;
+ for (int index = 0; index < 16; ++index)
+ fprintf(stderr, "%02X", (unsigned)byte_array[index]);
+ fprintf(stderr, "\n");
+
+ fprintf(stderr, "int8_avg_accum state %p\n", state);
+ fprintf(stderr, "int8_avg_accum %p\n", &int8_avg_accum);
+
if (!PG_ARGISNULL(1))
{
#ifdef HAVE_INT128
- do_int128_accum(state, (int128) PG_GETARG_INT64(1));
+ do_int128_accum(state, val_int128);
#else
Numeric newval;
@@ -4640,6 +4671,7 @@ numeric_poly_sum(PG_FUNCTION_ARGS)
Datum
numeric_poly_avg(PG_FUNCTION_ARGS)
{
+ fprintf(stderr, "numeric_poly_avg\n");
#ifdef HAVE_INT128
PolyNumAggState *state;
NumericVar result;
@@ -6365,6 +6397,17 @@ int128_to_numericvar(int128 val, NumericVar *var)
NumericDigit *ptr;
int ndigits;
+ fprintf(stderr, "int128_to_numericvar\n");
+
+ fprintf(stderr, "int128_to_numericvar int128 val as 2 x int64: %ld %ld\n",
+ (int64) (val >> 64), (int64) val);
+
+ fprintf(stderr, "int128_to_numericvar int128 val bytes: ");
+ unsigned char* byte_array = (void *) &val;
+ for (int index = 0; index < 16; ++index)
+ fprintf(stderr, "%02X", (unsigned)byte_array[index]);
+ fprintf(stderr, "\n");
+
/* int128 can require at most 39 decimal digits; add one for safety */
alloc_var(var, 40 / DEC_DIGITS);
if (val < 0)
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:13 Victor Wagner <vitus@wagner.pp.ru>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
3 siblings, 1 reply; 46+ messages in thread
From: Victor Wagner @ 2018-01-17 15:13 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
On Wed, 17 Jan 2018 18:02:26 +0300
Marina Polyakova <m.polyakova@postgrespro.ru> wrote:
> > Attached is a possible test program. I can confirm it passes on a
> > machine with working __int128, but I have no idea whether it will
> > detect the problem on yours. If not, maybe you can tweak it?
>
> Thank you! Using gcc 5.5.0 it prints that everything is ok. But,
> investigating the regression diffs, we found out that the error
> occurs when we pass int128 as not the first argument to the function
> (perhaps its value is replaced by the value of some address):
I'm attaching stripped-down version of test program, which demonstrate
the problem and two assembler listings produced with this C source using
alignment 8 and 16. May be this stripped-down version can be used as
base for configure test.
As it turns out, Sparc GCC passes function arguments via register ring
which is referenced as %on in the calling code and as %in in function.
And somehow it happens that alignment attribute of typedef affects
access to arguments in the function, but doesn't affect how regiser
ring is filled before call. Looks like bug in GCC.
Unfortunately, we have only one Sparc machine and started our
investigation by upgrading GCC 5.2.0 to GCC 5.5.0, so it is hard to
downgrade and test with older GCC.
--
Attachments:
align_test.c (text/x-c++src, 663B) download
#include <stddef.h>
#include <stdio.h>
# ifndef PG_ALIGN_128
#define PG_ALIGN_128 8
# endif
/* GCC, Sunpro and XLC support aligned */
#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#endif
typedef __int128 int128a
#if defined(pg_attribute_aligned)
pg_attribute_aligned(PG_ALIGN_128)
#endif
;
int128a holder;
void pass_by_val(void *buffer,int128a par) {
holder=par;
}
int
main()
{
long int i64 = 97656225L << 12;
int128a q;
pass_by_val(main,(int128a) i64);
q=(int128a) i64;
printf("pass int 64 %s\n",(q==holder)?"OK":"FAILED");
if (q!=holder)
return 1;
return 0;
}
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:28 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
3 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-17 15:28 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Please do that and let me know the PR number --- I think it would be
good to cite the bug specifically in the comments for our configure code.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:32 Victor Wagner <vitus@wagner.pp.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 46+ messages in thread
From: Victor Wagner @ 2018-01-17 15:32 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
On Wed, 17 Jan 2018 10:07:37 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> Yeah, I can work with this. What I propose to do is use a somewhat
> stripped-down version of this test as an AC_RUN_IFELSE test normally,
> but if cross-compiling, fall back to just seeing if we can link.
I'd suggest to add a configure option to switch off 128-bit support
(--disable-int128), especially for these cross-compile cases where link
test cannot give us enough information to decide automatically.
--
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:40 Tom Lane <tgl@sss.pgh.pa.us>
parent: Victor Wagner <vitus@wagner.pp.ru>
0 siblings, 0 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-17 15:40 UTC (permalink / raw)
To: Victor Wagner <vitus@wagner.pp.ru>; +Cc: pgsql-hackers@lists.postgresql.org
Victor Wagner <vitus@wagner.pp.ru> writes:
> On Wed, 17 Jan 2018 10:07:37 -0500
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, I can work with this. What I propose to do is use a somewhat
>> stripped-down version of this test as an AC_RUN_IFELSE test normally,
>> but if cross-compiling, fall back to just seeing if we can link.
> I'd suggest to add a configure option to switch off 128-bit support
> (--disable-int128), especially for these cross-compile cases where link
> test cannot give us enough information to decide automatically.
I don't want to go there without some evidence that the problem is much
more widespread than it appears now. A disable switch will be a permanent
documentation and maintenance overhead, plus anyone who puts it into
their build scripts will probably never remember to remove it :-(.
And how many people will be cross-compiling to Solaris/SPARC anyway?
(If there are any, they can always manually change pg_config.h ...)
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:42 Tom Lane <tgl@sss.pgh.pa.us>
parent: Victor Wagner <vitus@wagner.pp.ru>
0 siblings, 0 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-17 15:42 UTC (permalink / raw)
To: Victor Wagner <vitus@wagner.pp.ru>; +Cc: pgsql-hackers@lists.postgresql.org
Victor Wagner <vitus@wagner.pp.ru> writes:
> I'm attaching stripped-down version of test program, which demonstrate
> the problem and two assembler listings produced with this C source using
> alignment 8 and 16. May be this stripped-down version can be used as
> base for configure test.
Ah, thanks, this will be easier to work with.
> Unfortunately, we have only one Sparc machine and started our
> investigation by upgrading GCC 5.2.0 to GCC 5.5.0, so it is hard to
> downgrade and test with older GCC.
OK. Well, the fact that you get the same failures in PG itself seems
like good evidence that the compiler's behavior hasn't changed here.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:46 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-17 15:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 17-01-2018 18:07, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> investigating the regression diffs, we found out that the error occurs
>> when we pass int128 as not the first argument to the function (perhaps
>> its value is replaced by the value of some address):
>> ...
>> Based on this, we modified the test program (see attached). Here is
>> its
>> output on Solaris 10 for different alignments requirements for int128
>> (on my machine where make check-world passes everything is OK)
>> (ALIGNOF_PG_INT128_TYPE is 16 on Solaris 10):
>
> Excellent. This fails the same way on gcc 5.2.0 and 5.5.0?
As Victor answered in [1]:
> Unfortunately, we have only one Sparc machine and started our
> investigation by upgrading GCC 5.2.0 to GCC 5.5.0, so it is hard to
> downgrade and test with older GCC.
>> Maybe some pass test from int128test2.c can be used to test __int128?
>
> Yeah, I can work with this. What I propose to do is use a somewhat
> stripped-down version of this test as an AC_RUN_IFELSE test normally,
> but if cross-compiling, fall back to just seeing if we can link.
Thanks, I'll try to do this.. And Victor attached a stripped-down
version of this in [1].
> Thanks for investigating!
Thank you! :)
[1]
https://www.postgresql.org/message-id/20180117181359.3a6cc06c%40fafnir.local.vm
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:48 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 0 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-17 15:48 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 17-01-2018 18:07, Tom Lane wrote:
>> Yeah, I can work with this. What I propose to do is use a somewhat
>> stripped-down version of this test as an AC_RUN_IFELSE test normally,
>> but if cross-compiling, fall back to just seeing if we can link.
> Thanks, I'll try to do this.. And Victor attached a stripped-down
> version of this in [1].
Oh, I was already working on a patch, thanks.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 15:50 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-17 15:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 17-01-2018 18:28, Tom Lane wrote:
> BTW, now that you've demonstrated that the bug exists in a current
> gcc release, you should definitely file a bug at
> https://gcc.gnu.org/bugzilla/
> I think you can just give them int128test2.c as-is as a test case.
>
> Please do that and let me know the PR number --- I think it would be
> good to cite the bug specifically in the comments for our configure
> code.
Thanks, I'll try to do it.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-17 16:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
1 sibling, 3 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-17 16:33 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Attached is a draft patch to incorporate Victor's slimmed-down test
into configure. If you have a chance, could you confirm it does
the right thing on your Sparc machine?
BTW, it would be a good idea to set up a buildfarm member on that
machine, if you care about whether that configuration continues
to work in the future.
regards, tom lane
Attachments:
make-configure-check-for-gcc-bug.patch (text/x-diff, 7.4K) download
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 076656c..cbfccf6 100644
*** a/config/c-compiler.m4
--- b/config/c-compiler.m4
*************** AC_DEFUN([PGAC_TYPE_128BIT_INT],
*** 108,136 ****
[AC_CACHE_CHECK([for __int128], [pgac_cv__128bit_int],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([
/*
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants. We do not have
! * convenient support for 64bit literals at this point...
*/
__int128 a = 48828125;
! __int128 b = 97656255;
],[
__int128 c,d;
a = (a << 12) + 1; /* 200000000001 */
b = (b << 12) + 5; /* 400000000005 */
! /* use the most relevant arithmetic ops */
c = a * b;
d = (c + b) / b;
! /* return different values, to prevent optimizations */
if (d != a+1)
! return 0;
! return 1;
])],
[pgac_cv__128bit_int=yes],
[pgac_cv__128bit_int=no])])
if test x"$pgac_cv__128bit_int" = xyes ; then
! AC_DEFINE(PG_INT128_TYPE, __int128, [Define to the name of a signed 128-bit integer type.])
! AC_CHECK_ALIGNOF(PG_INT128_TYPE)
fi])# PGAC_TYPE_128BIT_INT
--- 108,166 ----
[AC_CACHE_CHECK([for __int128], [pgac_cv__128bit_int],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([
/*
+ * We don't actually run this test, just link it to verify that any support
+ * functions needed for __int128 are present.
+ *
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants. We do not have
! * convenient support for 128bit literals at this point...
*/
__int128 a = 48828125;
! __int128 b = 97656250;
],[
__int128 c,d;
a = (a << 12) + 1; /* 200000000001 */
b = (b << 12) + 5; /* 400000000005 */
! /* try the most relevant arithmetic ops */
c = a * b;
d = (c + b) / b;
! /* must use the results, else compiler may optimize arithmetic away */
if (d != a+1)
! return 1;
])],
[pgac_cv__128bit_int=yes],
[pgac_cv__128bit_int=no])])
if test x"$pgac_cv__128bit_int" = xyes ; then
! # Some versions of gcc have problems passing __int128 function arguments
! # when using non-default alignment. Test that, if not cross-compiling.
! AC_CACHE_CHECK([for __int128 alignment bug], [pgac_cv__128bit_int_bug],
! [AC_RUN_IFELSE([AC_LANG_PROGRAM([
! /* This must match the corresponding code in c.h: */
! #if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
! #define pg_attribute_aligned(a) __attribute__((aligned(a)))
! #endif
! typedef __int128 int128a
! #if defined(pg_attribute_aligned)
! pg_attribute_aligned(8)
! #endif
! ;
! int128a holder;
! void pass_by_val(void *buffer, int128a par) { holder = par; }
! ],[
! long int i64 = 97656225L << 12;
! int128a q;
! pass_by_val(main, (int128a) i64);
! q = (int128a) i64;
! if (q != holder)
! return 1;
! ])],
! [pgac_cv__128bit_int_bug=ok],
! [pgac_cv__128bit_int_bug=broken],
! [pgac_cv__128bit_int_bug=assuming-ok])])
! if test x"$pgac_cv__128bit_int_bug" != xbroken ; then
! AC_DEFINE(PG_INT128_TYPE, __int128, [Define to the name of a signed 128-bit integer type.])
! AC_CHECK_ALIGNOF(PG_INT128_TYPE)
! fi
fi])# PGAC_TYPE_128BIT_INT
diff --git a/configure b/configure
index 45221e1..6eaed45 100755
*** a/configure
--- b/configure
*************** else
*** 14996,15007 ****
/* end confdefs.h. */
/*
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants. We do not have
! * convenient support for 64bit literals at this point...
*/
__int128 a = 48828125;
! __int128 b = 97656255;
int
main ()
--- 14996,15010 ----
/* end confdefs.h. */
/*
+ * We don't actually run this test, just link it to verify that any support
+ * functions needed for __int128 are present.
+ *
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants. We do not have
! * convenient support for 128bit literals at this point...
*/
__int128 a = 48828125;
! __int128 b = 97656250;
int
main ()
*************** main ()
*** 15010,15022 ****
__int128 c,d;
a = (a << 12) + 1; /* 200000000001 */
b = (b << 12) + 5; /* 400000000005 */
! /* use the most relevant arithmetic ops */
c = a * b;
d = (c + b) / b;
! /* return different values, to prevent optimizations */
if (d != a+1)
! return 0;
! return 1;
;
return 0;
--- 15013,15024 ----
__int128 c,d;
a = (a << 12) + 1; /* 200000000001 */
b = (b << 12) + 5; /* 400000000005 */
! /* try the most relevant arithmetic ops */
c = a * b;
d = (c + b) / b;
! /* must use the results, else compiler may optimize arithmetic away */
if (d != a+1)
! return 1;
;
return 0;
*************** fi
*** 15033,15042 ****
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__128bit_int" >&5
$as_echo "$pgac_cv__128bit_int" >&6; }
if test x"$pgac_cv__128bit_int" = xyes ; then
$as_echo "#define PG_INT128_TYPE __int128" >>confdefs.h
! # The cast to long int works around a bug in the HP C Compiler,
# see AC_CHECK_SIZEOF for more information.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking alignment of PG_INT128_TYPE" >&5
$as_echo_n "checking alignment of PG_INT128_TYPE... " >&6; }
--- 15035,15097 ----
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__128bit_int" >&5
$as_echo "$pgac_cv__128bit_int" >&6; }
if test x"$pgac_cv__128bit_int" = xyes ; then
+ # Some versions of gcc have problems passing __int128 function arguments
+ # when using non-default alignment. Test that, if not cross-compiling.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for __int128 alignment bug" >&5
+ $as_echo_n "checking for __int128 alignment bug... " >&6; }
+ if ${pgac_cv__128bit_int_bug+:} false; then :
+ $as_echo_n "(cached) " >&6
+ else
+ if test "$cross_compiling" = yes; then :
+ pgac_cv__128bit_int_bug=assuming-ok
+ else
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h. */
+
+ /* This must match the corresponding code in c.h: */
+ #if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
+ #define pg_attribute_aligned(a) __attribute__((aligned(a)))
+ #endif
+ typedef __int128 int128a
+ #if defined(pg_attribute_aligned)
+ pg_attribute_aligned(8)
+ #endif
+ ;
+ int128a holder;
+ void pass_by_val(void *buffer, int128a par) { holder = par; }
+
+ int
+ main ()
+ {
+
+ long int i64 = 97656225L << 12;
+ int128a q;
+ pass_by_val(main, (int128a) i64);
+ q = (int128a) i64;
+ if (q != holder)
+ return 1;
+
+ ;
+ return 0;
+ }
+ _ACEOF
+ if ac_fn_c_try_run "$LINENO"; then :
+ pgac_cv__128bit_int_bug=ok
+ else
+ pgac_cv__128bit_int_bug=broken
+ fi
+ rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+ conftest.$ac_objext conftest.beam conftest.$ac_ext
+ fi
+
+ fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__128bit_int_bug" >&5
+ $as_echo "$pgac_cv__128bit_int_bug" >&6; }
+ if test x"$pgac_cv__128bit_int_bug" != xbroken ; then
$as_echo "#define PG_INT128_TYPE __int128" >>confdefs.h
! # The cast to long int works around a bug in the HP C Compiler,
# see AC_CHECK_SIZEOF for more information.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking alignment of PG_INT128_TYPE" >&5
$as_echo_n "checking alignment of PG_INT128_TYPE... " >&6; }
*************** cat >>confdefs.h <<_ACEOF
*** 15071,15076 ****
--- 15126,15132 ----
_ACEOF
+ fi
fi
# Check for various atomic operations now that we have checked how to declare
* Re: master make check fails on Solaris 10
@ 2018-01-17 17:36 Victor Wagner <vitus@wagner.pp.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 46+ messages in thread
From: Victor Wagner @ 2018-01-17 17:36 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
В Wed, 17 Jan 2018 11:33:09 -0500
Tom Lane <tgl@sss.pgh.pa.us> пишет:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?
>
Definitely. As soon as next work day begins in Moscow.
> BTW, it would be a good idea to set up a buildfarm member on that
> machine, if you care about whether that configuration continues
> to work in the future.
Really we already have buildfarm member on this machine. It is just
member of PostgresPro private buildfarm, not of big comminity
buildfarm.
So, I'll register it in the big buildfarm as soon as I figure out how
to distribute limited resources of this machine between two buildfarms.
--
Victor Wagner <vitus@wagner.pp.ru>
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 06:40 Victor Wagner <vitus@wagner.pp.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 46+ messages in thread
From: Victor Wagner @ 2018-01-18 06:40 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
On Wed, 17 Jan 2018 11:33:09 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?
It seems that what it does is not exactly a right thing.
I've applied it to commit 9c7d06d60680 in master and see following
$ ./configure CC="gcc -m64"
[skip]
checking for __int128... yes
checking for __int128 alignment bug... ok
checking alignment of PG_INT128_TYPE... 16
checking for builtin __sync char locking functions... yes
[skip]
As far as I understand your patch, there should be:
checking for __int128 alignment bug... broken
Then in the pg_config.h I see
/* The normal alignment of `PG_INT128_TYPE', in bytes. */
#define ALIGNOF_PG_INT128_TYPE 16
/* Define to the name of a signed 128-bit integer type. */
#define PG_INT128_TYPE __int128
However, make check passes.
There are two things which puzzle me
1. Why test program doesn't detect bug.
If I cut'n'paste it from configure, compile with flags, cut'n'pasted
from config log and run, it returns 1. But configure tells that all is
ok
2. If bug exist and is not detected by configure why make check passes.
We, Marina and I would continue investigation.
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 06:47 Tom Lane <tgl@sss.pgh.pa.us>
parent: Victor Wagner <vitus@wagner.pp.ru>
0 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-18 06:47 UTC (permalink / raw)
To: Victor Wagner <vitus@wagner.pp.ru>; +Cc: pgsql-hackers@lists.postgresql.org
Victor Wagner <vitus@wagner.pp.ru> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Attached is a draft patch to incorporate Victor's slimmed-down test
>> into configure. If you have a chance, could you confirm it does
>> the right thing on your Sparc machine?
> It seems that what it does is not exactly a right thing.
> I've applied it to commit 9c7d06d60680 in master and see following
> checking for __int128 alignment bug... ok
> As far as I understand your patch, there should be:
> checking for __int128 alignment bug... broken
Yes, that's what I expected to happen.
> Then in the pg_config.h I see
> /* The normal alignment of `PG_INT128_TYPE', in bytes. */
> #define ALIGNOF_PG_INT128_TYPE 16
> /* Define to the name of a signed 128-bit integer type. */
> #define PG_INT128_TYPE __int128
That's what I'd expect if configure thinks all's well :-(
> However, make check passes.
Uh ... how could that be? If the output of configure is exactly
the same as before the patch, how could the end result be different?
> We, Marina and I would continue investigation.
I look forward to some results ... but I'm going to bed now ...
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 09:53 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-18 09:53 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Thank you!
On 17-01-2018 19:33, Tom Lane wrote:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?
> Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> writes:
>> It seems that what it does is not exactly a right thing.
>> I've applied it to commit 9c7d06d60680 in master and see following
>> checking for __int128 alignment bug... ok
>> As far as I understand your patch, there should be:
>> checking for __int128 alignment bug... broken
> ...
>> Then in the pg_config.h I see
>> /* The normal alignment of `PG_INT128_TYPE', in bytes. */
>> #define ALIGNOF_PG_INT128_TYPE 16
>> /* Define to the name of a signed 128-bit integer type. */
>> #define PG_INT128_TYPE __int128
> ...
>> However, make check passes.
> Uh ... how could that be? If the output of configure is exactly
> the same as before the patch, how could the end result be different?
Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
and using the configuration command from [1], I got:
checking for __int128... yes
checking for __int128 alignment bug... broken
Nothing is defined for int128 in pg_config.h:
/* The normal alignment of `PG_INT128_TYPE', in bytes. */
/* #undef ALIGNOF_PG_INT128_TYPE */
...
/* Define to the name of a signed 128-bit integer type. */
/* #undef PG_INT128_TYPE */
And make check-world passes. Victor said that he used a much simpler
configuration command, and I'm trying to figure out what's changed..
> BTW, it would be a good idea to set up a buildfarm member on that
> machine, if you care about whether that configuration continues
> to work in the future.
Victor answered this in [2]:
> Really we already have buildfarm member on this machine. It is just
> member of PostgresPro private buildfarm, not of big comminity
> buildfarm.
>
> So, I'll register it in the big buildfarm as soon as I figure out how
> to distribute limited resources of this machine between two buildfarms.
P.S. I found the trailing whitespace in line 80:
! int128a q;
[1]
https://www.postgresql.org/message-id/0d3a9fa264cebe1cb9966f37b7c06e86%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/20180117203648.2626d97a%40wagner.wagner.home
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 14:43 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
1 sibling, 0 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-18 14:43 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 17-01-2018 18:50, Marina Polyakova wrote:
> On 17-01-2018 18:28, Tom Lane wrote:
>> BTW, now that you've demonstrated that the bug exists in a current
>> gcc release, you should definitely file a bug at
>> https://gcc.gnu.org/bugzilla/
>> I think you can just give them int128test2.c as-is as a test case.
>>
>> Please do that and let me know the PR number --- I think it would be
>> good to cite the bug specifically in the comments for our configure
>> code.
>
> Thanks, I'll try to do it.
If I understand correctly, its PR number is 83925 (see [1]).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83925
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 14:53 Victor Wagner <vitus@wagner.pp.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 46+ messages in thread
From: Victor Wagner @ 2018-01-18 14:53 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
On Thu, 18 Jan 2018 01:47:46 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Victor Wagner <vitus@wagner.pp.ru> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > checking for __int128 alignment bug... ok
> > As far as I understand your patch, there should be:
> > checking for __int128 alignment bug... broken
>
> Yes, that's what I expected to happen.
It seems that I've made some unreproducible mistake last night
applying your patch. Marina repeapplied it later and everything works.
I'we cherrypicked in as far back as 9.5, and with these versions it
works too.
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 14:56 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 2 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-18 14:56 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
> and using the configuration command from [1], I got:
> checking for __int128... yes
> checking for __int128 alignment bug... broken
> ...
> And make check-world passes. Victor said that he used a much simpler
> configuration command, and I'm trying to figure out what's changed..
Weird. Maybe the gcc bug only manifests with certain optimization
flags? That's not what I'd have expected from Victor's theory about
why the code is wrong, but if it only shows up some of the time,
it's hard to think of another explanation.
> P.S. I found the trailing whitespace in line 80:
> ! int128a q;
Ah, thanks. Probably git would've whined about that when I went
to commit, but it's good to catch sooner.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 15:05 Victor Wagner <vitus@wagner.pp.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 46+ messages in thread
From: Victor Wagner @ 2018-01-18 15:05 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
On Thu, 18 Jan 2018 09:56:48 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> > Applying your patch on commit
> > f033462d8f77c40b7d6b33c5116e50118fb4699d and using the
> > configuration command from [1], I got: checking for __int128... yes
> > checking for __int128 alignment bug... broken
> > ...
> > And make check-world passes. Victor said that he used a much
> > simpler configuration command, and I'm trying to figure out what's
> > changed..
>
> Weird. Maybe the gcc bug only manifests with certain optimization
> flags? That's not what I'd have expected from Victor's theory about
No. I've compiled test program without any optimizationf flags.
Just -m64, which tells compiler to generate 64-bit code.
(in 32-bit mode there is no __int128, so problem wouldn't manifest
inself).
From the other side, when I've tried to resolve issue with not worked
test, I've copied all gcc flags from config.log, and test program
returned 1 with exactly same flags.
Probably, I should have to regenerate configure with autoconf. instead
of applying patch to configure.
--
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 15:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Victor Wagner <vitus@wagner.pp.ru>
0 siblings, 0 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-18 15:19 UTC (permalink / raw)
To: Victor Wagner <vitus@wagner.pp.ru>; +Cc: pgsql-hackers@lists.postgresql.org, Marina Polyakova <m.polyakova@postgrespro.ru>
Victor Wagner <vitus@wagner.pp.ru> writes:
> It seems that I've made some unreproducible mistake last night
> applying your patch. Marina repeapplied it later and everything works.
Ah, thanks for following up. I'll adjust the comment to include the
gcc PR and push it shortly.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 16:42 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-18 16:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 18-01-2018 17:56, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
>> and using the configuration command from [1], I got:
>> checking for __int128... yes
>> checking for __int128 alignment bug... broken
>> ...
>> And make check-world passes. Victor said that he used a much simpler
>> configuration command, and I'm trying to figure out what's changed..
>
> Weird. Maybe the gcc bug only manifests with certain optimization
> flags? That's not what I'd have expected from Victor's theory about
> why the code is wrong, but if it only shows up some of the time,
> it's hard to think of another explanation.
Thank you! Using ./configure CC="gcc" CFLAGS="-m64 -O1" on commit
9c7d06d60680 with your patch, I got this:
checking for __int128... yes
checking for __int128 alignment bug... ok
checking alignment of PG_INT128_TYPE... 16
In pg_config.h:
/* The normal alignment of `PG_INT128_TYPE', in bytes. */
#define ALIGNOF_PG_INT128_TYPE 16
...
/* Define to the name of a signed 128-bit integer type. */
#define PG_INT128_TYPE __int128
But make check got the same failures, and I see the same debug output as
in [1]..
P.S. As I understand it, this comment on bugzilla [2] is also about
this.
[1]
https://www.postgresql.org/message-id/90ab676392c8f9c84431976147097cf0%40postgrespro.ru
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83925#c6
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 16:53 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-18 16:53 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 18-01-2018 17:56, Tom Lane wrote:
>> Weird. Maybe the gcc bug only manifests with certain optimization
>> flags? That's not what I'd have expected from Victor's theory about
>> why the code is wrong, but if it only shows up some of the time,
>> it's hard to think of another explanation.
> Thank you! Using ./configure CC="gcc" CFLAGS="-m64 -O1" on commit
> 9c7d06d60680 with your patch, I got this:
> [ configure check passes ]
> But make check got the same failures, and I see the same debug output as
> in [1]..
Interesting. Maybe the parameter-passing misbehavior that Victor's
test is looking for isn't the only associated bug.
> P.S. As I understand it, this comment on bugzilla [2] is also about
> this.
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83925#c6
Even more interesting, see c7 that was just posted there:
>> Eric Botcazou 2018-01-18 16:22:48 UTC
>> 128-bit types requite 128-bit alignment on SPARC64 so we cannot support that.
So basically, we're outta luck and we have to consider __int128 as
unsupportable on SPARC. I'm inclined to mechanize that as a test on
$host_cpu. At least that means we don't need an AC_RUN test ;-)
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 17:07 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-18 17:07 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 18-01-2018 19:53, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 18-01-2018 17:56, Tom Lane wrote:
>>> Weird. Maybe the gcc bug only manifests with certain optimization
>>> flags? That's not what I'd have expected from Victor's theory about
>>> why the code is wrong, but if it only shows up some of the time,
>>> it's hard to think of another explanation.
>
>> Thank you! Using ./configure CC="gcc" CFLAGS="-m64 -O1" on commit
>> 9c7d06d60680 with your patch, I got this:
>> [ configure check passes ]
>> But make check got the same failures, and I see the same debug output
>> as
>> in [1]..
>
> Interesting. Maybe the parameter-passing misbehavior that Victor's
> test is looking for isn't the only associated bug.
>
>> P.S. As I understand it, this comment on bugzilla [2] is also about
>> this.
>> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83925#c6
>
> Even more interesting, see c7 that was just posted there:
>
>>> Eric Botcazou 2018-01-18 16:22:48 UTC
>>> 128-bit types requite 128-bit alignment on SPARC64 so we cannot
>>> support that.
>
> So basically, we're outta luck and we have to consider __int128 as
> unsupportable on SPARC. I'm inclined to mechanize that as a test on
> $host_cpu. At least that means we don't need an AC_RUN test ;-)
%-)) :-)
Can I do something else about this problem?..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 17:24 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 3 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-18 17:24 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 18-01-2018 19:53, Tom Lane wrote:
>> So basically, we're outta luck and we have to consider __int128 as
>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
> %-)) :-)
> Can I do something else about this problem?..
I don't see any other workable alternative. The box we're in as far
as the interaction with MAXALIGN goes is still the same as it was
a month ago: raising MAXALIGN is impractical, and so is allowing
some datatypes to have more-than-MAXALIGN alignment specs.
I suppose you could imagine declaring int128s that are in any sort
of palloc'd storage as, in effect, char[16], and always memcpy'ing
to and from local variables that're declared int128 whenever you
want to do arithmetic with them. But ugh. I can't see taking that
sort of notational and performance hit for just one non-mainstream
architecture.
Really, this is something that the compiler ought to do for us, IMO.
If the gcc guys don't want to be bothered, OK, but that tells you more
about the priority they place on SPARC support than anything else.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 17:34 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 46+ messages in thread
From: Tom Lane @ 2018-01-18 17:34 UTC (permalink / raw)
To: Marina Polyakova <m.polyakova@postgrespro.ru>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
I wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
>> %-)) :-)
>> Can I do something else about this problem?..
> I don't see any other workable alternative.
But ... let's not panic, but wait and see the final result of the
discussion on the gcc PR. Jakub at least seems to think it ought
to be a supportable case.
What you could do in the meantime is work on finding a variation of
Victor's test that will detect the bug regardless of -O level.
If we do have hope that future gcc versions will handle this correctly,
we'll need a better test rather than just summarily dismissing
host_cpu = sparc.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 17:41 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-18 17:41 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 18-01-2018 20:24, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
>
>> %-)) :-)
>> Can I do something else about this problem?..
>
> I don't see any other workable alternative. The box we're in as far
> as the interaction with MAXALIGN goes is still the same as it was
> a month ago: raising MAXALIGN is impractical, and so is allowing
> some datatypes to have more-than-MAXALIGN alignment specs.
>
> I suppose you could imagine declaring int128s that are in any sort
> of palloc'd storage as, in effect, char[16], and always memcpy'ing
> to and from local variables that're declared int128 whenever you
> want to do arithmetic with them. But ugh. I can't see taking that
> sort of notational and performance hit for just one non-mainstream
> architecture.
>
> Really, this is something that the compiler ought to do for us, IMO.
> If the gcc guys don't want to be bothered, OK, but that tells you more
> about the priority they place on SPARC support than anything else.
Thank you very much for your explanations!
So I'll go to all of your comments to my patch about stable functions
when the next work day begins in Moscow)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 17:48 Robert Haas <robertmhaas@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 46+ messages in thread
From: Robert Haas @ 2018-01-18 17:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Marina Polyakova <m.polyakova@postgrespro.ru>; Victor Wagner *EXTERN* <vitus@wagner.pp.ru>; Andres Freund <andres@anarazel.de>; pgsql-hackers; Alvaro Herrera <alvherre@alvh.no-ip.org>
On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
>
>> %-)) :-)
>> Can I do something else about this problem?..
>
> I don't see any other workable alternative. The box we're in as far
> as the interaction with MAXALIGN goes is still the same as it was
> a month ago: raising MAXALIGN is impractical, and so is allowing
> some datatypes to have more-than-MAXALIGN alignment specs.
>
> I suppose you could imagine declaring int128s that are in any sort
> of palloc'd storage as, in effect, char[16], and always memcpy'ing
> to and from local variables that're declared int128 whenever you
> want to do arithmetic with them. But ugh. I can't see taking that
> sort of notational and performance hit for just one non-mainstream
> architecture.
It's not like we'd have to take the performance hit everywhere; we
could do the expensive things only on platforms that need them. The
trick would be to avoid too much notation. But it's not like we don't
live with a lot of DatumGetThing and ThingGetDatum notation already.
> Really, this is something that the compiler ought to do for us, IMO.
> If the gcc guys don't want to be bothered, OK, but that tells you more
> about the priority they place on SPARC support than anything else.
Of course, the same accusation could be leveled at us. We don't
require int128 support for correctness; we just use it for performance
where it's available and works the way we want. Prolly, that means
mainstream platforms. If we wanted to work harder, we could get it
working in other places too. Or some other fix that delivers much of
the same performance benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 17:49 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 46+ messages in thread
From: Marina Polyakova @ 2018-01-18 17:49 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 18-01-2018 20:34, Tom Lane wrote:
> I wrote:
> ...
> But ... let's not panic, but wait and see the final result of the
> discussion on the gcc PR. Jakub at least seems to think it ought
> to be a supportable case.
>
> What you could do in the meantime is work on finding a variation of
> Victor's test that will detect the bug regardless of -O level.
> If we do have hope that future gcc versions will handle this correctly,
> we'll need a better test rather than just summarily dismissing
> host_cpu = sparc.
Thanks, I'll try..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 18:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 2 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-18 18:03 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Marina Polyakova <m.polyakova@postgrespro.ru>; Victor Wagner *EXTERN* <vitus@wagner.pp.ru>; Andres Freund <andres@anarazel.de>; pgsql-hackers; Alvaro Herrera <alvherre@alvh.no-ip.org>
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Really, this is something that the compiler ought to do for us, IMO.
>> If the gcc guys don't want to be bothered, OK, but that tells you more
>> about the priority they place on SPARC support than anything else.
> Of course, the same accusation could be leveled at us. We don't
> require int128 support for correctness; we just use it for performance
> where it's available and works the way we want. Prolly, that means
> mainstream platforms. If we wanted to work harder, we could get it
> working in other places too. Or some other fix that delivers much of
> the same performance benefit.
Sure. Part of the equation here is that (IMO anyway) int128 isn't
sufficiently performance-critical to us to justify putting enormous
amounts of work into trying to make it go on non-mainstream platforms.
It's possible that that could change in future ... but if part of the
cost is notational changes that make it harder and more bug-prone
to use int128 at all, then I daresay int128 will never become that
performance-critical, because it would always remain a niche thing.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 18:24 Robert Haas <robertmhaas@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 46+ messages in thread
From: Robert Haas @ 2018-01-18 18:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Marina Polyakova <m.polyakova@postgrespro.ru>; Victor Wagner *EXTERN* <vitus@wagner.pp.ru>; Andres Freund <andres@anarazel.de>; pgsql-hackers; Alvaro Herrera <alvherre@alvh.no-ip.org>
On Thu, Jan 18, 2018 at 1:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sure. Part of the equation here is that (IMO anyway) int128 isn't
> sufficiently performance-critical to us to justify putting enormous
> amounts of work into trying to make it go on non-mainstream platforms.
> It's possible that that could change in future ... but if part of the
> cost is notational changes that make it harder and more bug-prone
> to use int128 at all, then I daresay int128 will never become that
> performance-critical, because it would always remain a niche thing.
That's possible. On the other hand, we lived for many years with
painful workarounds for systems without working 64-bit integers, and
those eventually became mainstream enough that we made them mandatory
- and then ripped out some of the notational changes that we'd
introduced to cope with platforms that didn't support them. So, the
same thing might happen here, whatever we decide about this. Then
again, 64 bit counters are already so large that it's hard to imagine
ever having one overflow, so perhaps 128-bit values will never catch
on in quite the same way. On the third hand, 640kB ought to be enough
for anybody.
Anyway, that's really an academic debate. My real point is: I do not
think we should reject out of hand the idea that a patch introducing
some new notation to deal with this might be acceptable. I am not
volunteering to write such a patch, and anyone who tries should be
aware that there is a chance that it will be rejected on grounds of
ugliness. However, if they decide to try anyway, we should read the
patch and see how ugly it really is. Maybe it's not that bad.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-18 18:28 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 46+ messages in thread
From: Tom Lane @ 2018-01-18 18:28 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Marina Polyakova <m.polyakova@postgrespro.ru>; Victor Wagner *EXTERN* <vitus@wagner.pp.ru>; Andres Freund <andres@anarazel.de>; pgsql-hackers; Alvaro Herrera <alvherre@alvh.no-ip.org>
Robert Haas <robertmhaas@gmail.com> writes:
> Anyway, that's really an academic debate. My real point is: I do not
> think we should reject out of hand the idea that a patch introducing
> some new notation to deal with this might be acceptable. I am not
> volunteering to write such a patch, and anyone who tries should be
> aware that there is a chance that it will be rejected on grounds of
> ugliness. However, if they decide to try anyway, we should read the
> patch and see how ugly it really is. Maybe it's not that bad.
Sure. I'm not intending to write such a patch either.
regards, tom lane
^ permalink raw reply [nested|flat] 46+ messages in thread
* Re: master make check fails on Solaris 10
@ 2018-01-20 14:40 Marina Polyakova <m.polyakova@postgrespro.ru>
parent: Marina Polyakova <m.polyakova@postgrespro.ru>
0 siblings, 0 replies; 46+ messages in thread
From: Marina Polyakova @ 2018-01-20 14:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
On 18-01-2018 20:49, Marina Polyakova wrote:
> On 18-01-2018 20:34, Tom Lane wrote:
>> ...
>> What you could do in the meantime is work on finding a variation of
>> Victor's test that will detect the bug regardless of -O level.
>> If we do have hope that future gcc versions will handle this
>> correctly,
>> we'll need a better test rather than just summarily dismissing
>> host_cpu = sparc.
>
> Thanks, I'll try..
I tried different options of gcc but it did not help..
Perhaps searching in the source code of gcc will clarify something, but
I'm sorry that I'm now too busy for this..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 46+ messages in thread
end of thread, other threads:[~2018-01-20 14:40 UTC | newest]
Thread overview: 46+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-01-11 17:21 master make check fails on Solaris 10 Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-11 17:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-12 08:37 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-11 17:39 ` Andres Freund <andres@anarazel.de>
2018-01-12 11:05 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-12 15:12 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2018-01-12 15:15 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-12 17:50 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-12 18:00 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-13 09:40 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-13 18:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-15 12:07 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-15 23:41 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 15:02 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-17 15:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 15:32 ` Victor Wagner <vitus@wagner.pp.ru>
2018-01-17 15:40 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 15:46 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-17 15:48 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 15:12 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-17 15:13 ` Victor Wagner <vitus@wagner.pp.ru>
2018-01-17 15:42 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 15:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 15:50 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-17 16:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-17 17:36 ` Victor Wagner <vitus@wagner.pp.ru>
2018-01-18 06:40 ` Victor Wagner <vitus@wagner.pp.ru>
2018-01-18 06:47 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 14:53 ` Victor Wagner <vitus@wagner.pp.ru>
2018-01-18 15:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 09:53 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-18 14:56 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 15:05 ` Victor Wagner <vitus@wagner.pp.ru>
2018-01-18 16:42 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-18 16:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 17:07 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-18 17:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 17:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 17:49 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-20 14:40 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-18 17:41 ` Marina Polyakova <m.polyakova@postgrespro.ru>
2018-01-18 17:48 ` Robert Haas <robertmhaas@gmail.com>
2018-01-18 18:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 18:24 ` Robert Haas <robertmhaas@gmail.com>
2018-01-18 18:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-01-18 14:43 ` Marina Polyakova <m.polyakova@postgrespro.ru>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox