Обсуждение: Regression test fails v9.2.4
Hi all…
In my organisation we build PG from source on SLES11.2 using GCC 4.3.
Versions 9.1.x of Postgresql and earlier always passed all of the regression tests but 9.2.3 and .4 fail on the following :
Union
Join
Select views
Polymorphism
With
This happens when using gmake check & gmake MAX_CONNECTIONS=10 installcheck
Mostly the fails are because the returned data order doesn’t match the expected results. Another significant example is this output from the ‘union’ test :
*** /data/vdrive/Workspaces/jsm/apx/apx_system_fix_S4/ds_pgres/source/postgresql-9.2.4/src/test/regress/expected/union.out Mon Apr 1 19:20:36 2013
--- /data/vdrive/Workspaces/jsm/apx/apx_system_fix_S4/ds_pgres/source/postgresql-9.2.4/src/test/regress/results/union.out Fri Apr 19 15:21:59 2013
***************
*** 490,504 ****
UNION
SELECT * FROM t2) t
WHERE ab = 'ab';
! QUERY PLAN
! ---------------------------------------------------
! HashAggregate
! -> Append
! -> Index Scan using t1_ab_idx on t1
! Index Cond: ((a || b) = 'ab'::text)
! -> Index Only Scan using t2_pkey on t2
! Index Cond: (ab = 'ab'::text)
! (6 rows)
reset enable_seqscan;
reset enable_indexscan;
--- 490,506 ----
UNION
SELECT * FROM t2) t
WHERE ab = 'ab';
! QUERY PLAN
! ---------------------------------------------------------
! Unique
! -> Sort
! Sort Key: ((t1.a || t1.b))
! -> Append
! -> Index Scan using t1_ab_idx on t1
! Index Cond: ((a || b) = 'ab'::text)
! -> Index Only Scan using t2_pkey on t2
! Index Cond: (ab = 'ab'::text)
! (8 rows)
reset enable_seqscan;
reset enable_indexscan;
Sorry for the rambling question : is this problem common, i.e. the expected results files need to be changed or… is it just me? J
Regards,
John Manning
Business & Application Services
Fujitsu
Central Park, Northampton Road, Manchester, M40 5BP
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU.
Sorry – replying to my own question….
It seems that the problem only occurs when configuring the make with these settings :
--with-libraries=/lib64 --with-blocksize=2 --with-wal-blocksize=2
Now, we *could* do a two phase compile, one to perform regression tests and another for deployment. Clearly we don’t want to do that.
Regards,
John Manning
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Manning John
Sent: 22 April 2013 11:52
To: pgsql-general@postgresql.org
Subject: [GENERAL] Regression test fails v9.2.4
Hi all…
In my organisation we build PG from source on SLES11.2 using GCC 4.3.
Versions 9.1.x of Postgresql and earlier always passed all of the regression tests but 9.2.3 and .4 fail on the following :
Union
Join
Select views
Polymorphism
With
This happens when using gmake check & gmake MAX_CONNECTIONS=10 installcheck
Mostly the fails are because the returned data order doesn’t match the expected results. Another significant example is this output from the ‘union’ test :
*** /data/vdrive/Workspaces/jsm/apx/apx_system_fix_S4/ds_pgres/source/postgresql-9.2.4/src/test/regress/expected/union.out Mon Apr 1 19:20:36 2013
--- /data/vdrive/Workspaces/jsm/apx/apx_system_fix_S4/ds_pgres/source/postgresql-9.2.4/src/test/regress/results/union.out Fri Apr 19 15:21:59 2013
***************
*** 490,504 ****
UNION
SELECT * FROM t2) t
WHERE ab = 'ab';
! QUERY PLAN
! ---------------------------------------------------
! HashAggregate
! -> Append
! -> Index Scan using t1_ab_idx on t1
! Index Cond: ((a || b) = 'ab'::text)
! -> Index Only Scan using t2_pkey on t2
! Index Cond: (ab = 'ab'::text)
! (6 rows)
reset enable_seqscan;
reset enable_indexscan;
--- 490,506 ----
UNION
SELECT * FROM t2) t
WHERE ab = 'ab';
! QUERY PLAN
! ---------------------------------------------------------
! Unique
! -> Sort
! Sort Key: ((t1.a || t1.b))
! -> Append
! -> Index Scan using t1_ab_idx on t1
! Index Cond: ((a || b) = 'ab'::text)
! -> Index Only Scan using t2_pkey on t2
! Index Cond: (ab = 'ab'::text)
! (8 rows)
reset enable_seqscan;
reset enable_indexscan;
Sorry for the rambling question : is this problem common, i.e. the expected results files need to be changed or… is it just me? J
Regards,
John Manning
Business & Application Services
Fujitsu
Central Park, Northampton Road, Manchester, M40 5BP
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU.
Manning John <John.Manning@uk.fujitsu.com> wrote: > [regression tests have different plans or row orderings] > It seems that the problem only occurs when configuring the make > with these settings : > > --with-libraries=/lib64 --with-blocksize=2 --with-wal-blocksize=2 > is this problem common, i.e. the expected results files need to > be changed ... ? I don't find it too surprising that a different page size could cause different plans to be chosen or different row orderings. After verifying that the differences are benign, you could add alternative "expected" files for your build environment. I can't help being a little curious why you are overriding these defaults. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
>> [regression tests have different plans or row orderings] >> It seems that the problem only occurs when configuring the make >> with these settings : >> >> --with-libraries=/lib64 --with-blocksize=2 --with-wal-blocksize=2 >> is this problem common, i.e. the expected results files need to >> be changed ... ? >I don't find it too surprising that a different page size could >cause different plans to be chosen or different row orderings. >After verifying that the differences are benign, you could add >alternative "expected" files for your build environment. >I can't help being a little curious why you are overriding these >defaults. Thanks Kevin, we made the changes for query performance reasons. Our schema is such that the changes above make enough ofan impact to make it worthwhile. I think we're now looking at a two-phase validation process; an initial regression test on any new version we take then afurther check using our settings. I guess it's actually more useful that we must now inspect the results since it mighthelp us to squeeze even more performance boosts out of Postgresql. All the best, John Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from FujitsuTelecommunications Europe Limited, together "Fujitsu". This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free. Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW. Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW. PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road,Hayes, Middlesex, UB4 8FE. Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, BirminghamBusiness Park, Birmingham, B37 7YU.