Re: [GENERAL] Regression test fails v9.2.4
>> [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 of an 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 a further check using our settings. I guess it's actually more useful that we must now inspect the results since it might help 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 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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Regression test fails v9.2.4
Manning John 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Regression test fails v9.2.4
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-ow...@postgresql.org [mailto:pgsql-general-ow...@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? :) 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.
[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? :) 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.
