Re: [HACKERS] CSV arm check failure
Am Donnerstag, 6. Januar 2005 17:39 schrieb Jim Buttafuoco: I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL tests passed. OK, that's good enough. At least we found the cause of the problem. Future generations can look in the archives if they are interested in that kind of detail. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco: ARM platform fails the point test see below. For the 7.4 release we got a report for the ARM platform where all tests passed: http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote: Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco: ARM platform fails the point test see below. For the 7.4 release we got a report for the ARM platform where all tests passed: http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? Yes, there are various degrees of those, but most of them should be FPU-less. So FPU-emulation details would be interesting. In case of Linux there are 3 variants: NWFPE: default FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE gcc -msoft-float: no FP instructions, direct calls. This changes calling convention, so requires that all code is compiled with this. Jim, do you happen to use FastFPE? -- marko ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CSV arm check failure
it looks like a sqrt problem that has been fixed with the linux 2.6 kernel series. I am going to look and see if I can get a 2.6 kernel to check it out. since all of the other tests pass, maybe just a note in the read me file. Jim -- Original Message --- From: Peter Eisentraut [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 10:18:58 +0100 Subject: Re: [HACKERS] CSV arm check failure Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco: ARM platform fails the point test see below. For the 7.4 release we got a report for the ARM platform where all tests passed: http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org --- End of Original Message --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CSV arm check failure
Marko, I am using the stock Debian 2.4.27 kernel. Don't know how to change the fp setup. Do you have any instructions for me? Thanks Jim -- Original Message --- From: Marko Kreen marko@l-t.ee To: Peter Eisentraut [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 15:26:05 +0200 Subject: Re: [HACKERS] CSV arm check failure On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote: Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco: ARM platform fails the point test see below. For the 7.4 release we got a report for the ARM platform where all tests passed: http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? Yes, there are various degrees of those, but most of them should be FPU-less. So FPU-emulation details would be interesting. In case of Linux there are 3 variants: NWFPE: default FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE gcc -msoft-float: no FP instructions, direct calls. This changes calling convention, so requires that all code is compiled with this. Jim, do you happen to use FastFPE? -- marko ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match --- End of Original Message --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 09:07:14AM -0500, Jim Buttafuoco wrote: I am using the stock Debian 2.4.27 kernel. Don't know how to change the fp setup. Do you have any instructions for me? It can be changed by configuring and recompiling kernel. I checked the kernel-image-2.4.27-arm package from Debian/testing and indeed it uses FastFPE emulation. To be specific, the 'bast' and 'netwinder' targets do. The 'lart', 'riscpc' and 'riscstation' targets use NWFPE. I guess 'lart' and 'bast' are some devel boards and 'netwinder' is the main target. Looking at handhelds.org kernels they mostly use NWFPE although there are couple of configs with FastFPE. I have no clue on other Linux distros or *BSD's on ARM. It seems PostgreSQL may encounter both NWFPE and FastFPE on Linux/ARM. How to handle this I do not know. -- marko ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
Marko/All,
I wrote the following test program
#include stdio.h
#include math.h
#define HYPOT(A, B) sqrt((A) * (A) + (B) * (B))
int main()
{
printf(SQRT Test\n);
long double a;
a = HYPOT(0-10,0-10);
printf(double a = %20.12Lf\n,a);
exit(0);
}
and compiled it as follows
gcc -lm -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -g -o sqrttest sqrt.c
with the following results:
SQRT Test
double a = 14.142135623731
which is the exact answer in the results file for point.
Now if I use perl instead of C I get the wrong answer 14.1421356237309 which
is what postgres is also reporting. So
this looks like a compile time problem which is alittle over my head.
Any idea's
Jim
Jim
-- Original Message ---
From: Marko Kreen marko@l-t.ee
To: Peter Eisentraut [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thu, 6 Jan 2005 15:26:05 +0200
Subject: Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
ARM platform fails the point test see below.
For the 7.4 release we got a report for the ARM platform where all tests
passed:
http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php
So either there are various degrees of ARM processors or something is
broken.
Ideas?
Yes, there are various degrees of those, but most of them should be
FPU-less. So FPU-emulation details would be interesting.
In case of Linux there are 3 variants:
NWFPE: default
FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE
gcc -msoft-float: no FP instructions, direct calls. This
changes calling convention, so requires that all
code is compiled with this.
Jim, do you happen to use FastFPE?
--
marko
--- End of Original Message ---
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote: For the 7.4 release we got a report for the ARM platform where all tests passed: http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php Additional info point: (sid)noel ( at ) debussy:~/postgresql-cvs/pgsql$ uname -a Linux debussy 2.4.19-netwinder #1 Thu Mar 20 03:14:34 CET 2003 armv4l GNU/Linux I am guessing: the distro was Debian. I cant find 2.4.19-netwinder kernel but 2.4.16-netwinder from Debian/stable uses NWFPE. o Debian has changed from NWFPE to FastFPE at some point in time. -- marko ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
Marko, See my email with test program. I will recompile the kernel and get back to the list Jim -- Original Message --- From: Marko Kreen marko@l-t.ee To: Jim Buttafuoco [EMAIL PROTECTED] Cc: Peter Eisentraut [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 16:58:03 +0200 Subject: Re: [HACKERS] CSV arm check failure On Thu, Jan 06, 2005 at 09:07:14AM -0500, Jim Buttafuoco wrote: I am using the stock Debian 2.4.27 kernel. Don't know how to change the fp setup. Do you have any instructions for me? It can be changed by configuring and recompiling kernel. I checked the kernel-image-2.4.27-arm package from Debian/testing and indeed it uses FastFPE emulation. To be specific, the 'bast' and 'netwinder' targets do. The 'lart', 'riscpc' and 'riscstation' targets use NWFPE. I guess 'lart' and 'bast' are some devel boards and 'netwinder' is the main target. Looking at handhelds.org kernels they mostly use NWFPE although there are couple of configs with FastFPE. I have no clue on other Linux distros or *BSD's on ARM. It seems PostgreSQL may encounter both NWFPE and FastFPE on Linux/ARM. How to handle this I do not know. -- marko --- End of Original Message --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco wrote: I will recompile the kernel and get back to the list Thanks. This way we can be sure it is FP-emulation effect. -- marko ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
Marko, I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL tests passed. So I will file a bug report with Debian. We should also put something in the Postgresql readme about this issue. Jim -- Original Message --- From: Marko Kreen marko@l-t.ee To: Jim Buttafuoco [EMAIL PROTECTED] Cc: Peter Eisentraut [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 17:25:20 +0200 Subject: Re: [HACKERS] CSV arm check failure On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco wrote: I will recompile the kernel and get back to the list Thanks. This way we can be sure it is FP-emulation effect. -- marko ---(end of broadcast)--- TIP 8: explain analyze is your friend --- End of Original Message --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote: I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL tests passed. So I will file a bug report with Debian. We should also put something in the Postgresql readme about this issue. I do not think its bug in Debian or kernel - it is expected and documented behaviour of FastFPE to have less precision. Also if you think of ARM usage scenarious it seems fine to use lighter emulation. The question is rather how to handle it in PostgreSQL regression testing: 1) Document the need for NWFPE - which gives standard results. 2) Use FastFPE results on Linux/ARM. 3) Autodetect - ok, that was a joke. I guess 1) is fine now. 2) should be done when FastFPE is standard on Linux/ARM. -- marko ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CSV arm check failure
Marko Kreen wrote: On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote: I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL tests passed. So I will file a bug report with Debian. We should also put something in the Postgresql readme about this issue. I do not think its bug in Debian or kernel - it is expected and documented behaviour of FastFPE to have less precision. Also if you think of ARM usage scenarious it seems fine to use lighter emulation. The question is rather how to handle it in PostgreSQL regression testing: 1) Document the need for NWFPE - which gives standard results. 2) Use FastFPE results on Linux/ARM. 3) Autodetect - ok, that was a joke. I guess 1) is fine now. 2) should be done when FastFPE is standard on Linux/ARM. Why not just add an alternative regression output? pg_regress is designed to handle it, and we have quite a few of those already to deal with minor FP differences. Reminder: here is the complete set of diffs: *** ./expected/point.outTue Jan 4 10:55:16 2005 --- ./results/point.out Tue Jan 4 12:40:50 2005 *** *** 101,107 | (-3,4) |5 | (-10,0)| 10 | (-5,-12) | 13 ! | (10,10)| 14.142135623731 | (5.1,34.5) | 34.8749193547455 (6 rows) --- 101,107 | (-3,4) |5 | (-10,0)| 10 | (-5,-12) | 13 ! | (10,10)| 14.1421356237309 | (5.1,34.5) | 34.8749193547455 (6 rows) *** *** 127,134 | (-5,-12) | (-10,0)| 13 | (-5,-12) | (0,0) | 13 | (0,0) | (-5,-12) | 13 !| (0,0) | (10,10)| 14.142135623731 !| (10,10)| (0,0) | 14.142135623731 | (-3,4) | (10,10)| 14.3178210632764 | (10,10)| (-3,4) | 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 --- 127,134 | (-5,-12) | (-10,0)| 13 | (-5,-12) | (0,0) | 13 | (0,0) | (-5,-12) | 13 !| (0,0) | (10,10)| 14.1421356237309 !| (10,10)| (0,0) | 14.1421356237309 | (-3,4) | (10,10)| 14.3178210632764 | (10,10)| (-3,4) | 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 *** *** 198,204 | (-10,0)| (0,0) | 10 | (-10,0)| (-5,-12) | 13 | (-5,-12) | (0,0) | 13 ! | (0,0) | (10,10)| 14.142135623731 | (-3,4) | (10,10)| 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 | (-10,0)| (10,10)| 22.3606797749979 --- 198,204 | (-10,0)| (0,0) | 10 | (-10,0)| (-5,-12) | 13 | (-5,-12) | (0,0) | 13 ! | (0,0) | (10,10)| 14.1421356237309 | (-3,4) | (10,10)| 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 | (-10,0)| (10,10)| 22.3606797749979 cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 12:32:12PM -0500, Andrew Dunstan wrote:
Marko Kreen wrote:
The question is rather how to handle it in PostgreSQL
regression testing:
1) Document the need for NWFPE - which gives standard results.
2) Use FastFPE results on Linux/ARM.
3) Autodetect - ok, that was a joke.
I guess 1) is fine now. 2) should be done when FastFPE is
standard on Linux/ARM.
Why not just add an alternative regression output? pg_regress is
designed to handle it, and we have quite a few of those already to deal
with minor FP differences.
I have not looked at pg_regress much and had not noticed the
'unconditional alternative' feature. I only thought of the
resultmap alternative. Unconditionally adding FastFPE results
may even be good, so that FastFPE can pass on any platform.
Here are Jim's FastFPE 'point' results in separate file.
Unfortunately I have not an ARM machine to test it on.
Jim, could you apply this patch and run 'make check' on the
FastFPE kernel. If you encounter more small FP errors,
then simply copy results/test.out to expected/test_X.out
where X is a next free number.
Then send resulting files to this list.
--
marko
*** /dev/null 2005-01-04 07:18:19.0 +0200
--- src/test/regress/expected/point_1.out 2005-01-06 19:58:45.0
+0200
***
*** 0
--- 1,225
+ --
+ -- POINT
+ --
+ CREATE TABLE POINT_TBL(f1 point);
+ INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
+ -- bad format points
+ INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
+ ERROR: invalid input syntax for type point: asdfasdf
+ INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
+ INSERT INTO POINT_TBL(f1) VALUES ('(10.0 10.0)');
+ ERROR: invalid input syntax for type point: (10.0 10.0)
+ INSERT INTO POINT_TBL(f1) VALUES ('(10.0,10.0');
+ ERROR: invalid input syntax for type point: (10.0,10.0
+ SELECT '' AS six, POINT_TBL.*;
+ six | f1
+ -+
+ | (0,0)
+ | (-10,0)
+ | (-3,4)
+ | (5.1,34.5)
+ | (-5,-12)
+ | (10,10)
+ (6 rows)
+
+ -- left of
+ SELECT '' AS three, p.* FROM POINT_TBL p WHERE p.f1 '(0.0, 0.0)';
+ three |f1
+ ---+--
+| (-10,0)
+| (-3,4)
+| (-5,-12)
+ (3 rows)
+
+ -- right of
+ SELECT '' AS three, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' p.f1;
+ three |f1
+ ---+--
+| (-10,0)
+| (-3,4)
+| (-5,-12)
+ (3 rows)
+
+ -- above
+ SELECT '' AS one, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' ^ p.f1;
+ one |f1
+ -+--
+ | (-5,-12)
+ (1 row)
+
+ -- below
+ SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ^ '(0.0, 0.0)';
+ one |f1
+ -+--
+ | (-5,-12)
+ (1 row)
+
+ -- equal
+ SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ~= '(5.1, 34.5)';
+ one | f1
+ -+
+ | (5.1,34.5)
+ (1 row)
+
+ -- point in box
+ SELECT '' AS three, p.* FROM POINT_TBL p
+WHERE p.f1 @ box '(0,0,100,100)';
+ three | f1
+ ---+
+| (0,0)
+| (5.1,34.5)
+| (10,10)
+ (3 rows)
+
+ SELECT '' AS three, p.* FROM POINT_TBL p
+WHERE not p.f1 @ box '(0,0,100,100)';
+ three |f1
+ ---+--
+| (-10,0)
+| (-3,4)
+| (-5,-12)
+ (3 rows)
+
+ SELECT '' AS two, p.* FROM POINT_TBL p
+WHERE p.f1 @ path '[(0,0),(-10,0),(-10,10)]';
+ two | f1
+ -+-
+ | (0,0)
+ | (-10,0)
+ (2 rows)
+
+ SELECT '' AS six, p.f1, p.f1 - point '(0,0)' AS dist
+FROM POINT_TBL p
+ORDER BY dist;
+ six | f1 | dist
+ -++--
+ | (0,0) |0
+ | (-3,4) |5
+ | (-10,0)| 10
+ | (-5,-12) | 13
+ | (10,10)| 14.1421356237309
+ | (5.1,34.5) | 34.8749193547455
+ (6 rows)
+
+ SET geqo TO 'off';
+ SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 - p2.f1 AS
dist
+FROM POINT_TBL p1, POINT_TBL p2
+ORDER BY dist, point1 using , point2 using ;
+ thirtysix | point1 | point2 | dist
+ ---+++--
+| (-10,0)| (-10,0)|0
+| (-5,-12) | (-5,-12) |0
+| (-3,4) | (-3,4) |0
+| (0,0) | (0,0) |0
+| (5.1,34.5) | (5.1,34.5) |0
+| (10,10)| (10,10)|0
+| (-3,4) | (0,0) |5
+| (0,0) | (-3,4) |5
+| (-10,0)| (-3,4) | 8.06225774829855
+| (-3,4) | (-10,0)|
Re: [HACKERS] CSV arm check failure
Marko Kreen marko@l-t.ee writes: I have not looked at pg_regress much and had not noticed the 'unconditional alternative' feature. I only thought of the resultmap alternative. Unconditionally adding FastFPE results may even be good, so that FastFPE can pass on any platform. No, it would be bad, because on most other platforms this behavior is probably a bug, and altering the tests like that would mask the bug. The unconditional-acceptance thing has to be used with great caution; preferably only for issues that we expect on many platforms (such as locale dependencies). I have noticed an increasing tendency among the buildfarm crew to think that the regression tests should show zero diffs on all platforms no matter what. That is not the design goal. The intent is to tell you about possible problems. If you decide that a particular diff isn't really a problem, fine, but that doesn't mean we should mask the same symptom everywhere. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CSV arm check failure
Tom Lane wrote: I have noticed an increasing tendency among the buildfarm crew to think that the regression tests should show zero diffs on all platforms no matter what. That is not the design goal. The intent is to tell you about possible problems. If you decide that a particular diff isn't really a problem, fine, but that doesn't mean we should mask the same symptom everywhere. I don't want to mask anything that shouldn't be. I made the suggestion in this particular case because we already have a number of alternative result files caused by FP differences. The buildfarm is a dashboard application - when everything is OK you want it to show all green. If that's not a goal, then some redesign is appropriate. Perhaps buildfarm needs its own test suite, rather than leveraging those in the distribution, although that would be a pity, to say the least. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 02:05:17PM -0500, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
I have not looked at pg_regress much and had not noticed the
'unconditional alternative' feature. I only thought of the
resultmap alternative. Unconditionally adding FastFPE results
may even be good, so that FastFPE can pass on any platform.
No, it would be bad, because on most other platforms this behavior
is probably a bug, and altering the tests like that would mask the bug.
The unconditional-acceptance thing has to be used with great caution;
preferably only for issues that we expect on many platforms (such as
locale dependencies).
How about the following then: let pg_regress.sh accept multiple
choices from resultmap.
--
marko
Index: src/test/regress/pg_regress.sh
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/pg_regress.sh,v
retrieving revision 1.51
diff -u -c -r1.51 pg_regress.sh
*** src/test/regress/pg_regress.sh 12 Dec 2004 15:34:15 - 1.51
--- src/test/regress/pg_regress.sh 6 Jan 2005 19:30:52 -
***
*** 669,681
# to a system-specific expected file.
# There shouldn't be multiple matches, but take the last if there are.
! EXPECTED=$inputdir/expected/${name}
for LINE in $SUBSTLIST
do
if [ `expr $LINE : $name=` -ne 0 ]
then
! SUBST=`echo $LINE | sed 's/^.*=//'`
! EXPECTED=$inputdir/expected/${SUBST}
fi
done
--- 669,680
# to a system-specific expected file.
# There shouldn't be multiple matches, but take the last if there are.
! SUBST_VALS=${name}
for LINE in $SUBSTLIST
do
if [ `expr $LINE : $name=` -ne 0 ]
then
! SUBST_VALS=`echo $LINE | sed -e 's/^.*=//' -e 's/,/ /g'`
fi
done
***
*** 684,701
bestfile=
bestdiff=
! result=2
! for thisfile in $EXPECTED.out ${EXPECTED}_[0-9].out; do
! [ ! -r $thisfile ] continue
! diff $DIFFFLAGS $thisfile $outputdir/results/${name}.out
/dev/null 21
! result=$?
case $result in
0) break;;
- 1) thisdiff=`diff $DIFFFLAGS $thisfile
$outputdir/results/${name}.out | wc -l`
-if [ -z $bestdiff ] || [ $thisdiff -lt $bestdiff ];
then
-bestdiff=$thisdiff; bestfile=$thisfile
-fi
-continue;;
2) break;;
esac
done
--- 683,707
bestfile=
bestdiff=
! for SUBST in $SUBST_VALS; do
! EXPECTED=$inputdir/expected/${SUBST}
! result=2
! for thisfile in $EXPECTED.out ${EXPECTED}_[0-9].out; do
! [ ! -r $thisfile ] continue
! diff $DIFFFLAGS $thisfile $outputdir/results/${name}.out
/dev/null 21
! result=$?
! case $result in
! 0) break;;
! 1) thisdiff=`diff $DIFFFLAGS $thisfile
$outputdir/results/${name}.out | wc -l`
!if [ -z $bestdiff ] || [ $thisdiff -lt $bestdiff
]; then
!bestdiff=$thisdiff; bestfile=$thisfile
!fi
!continue;;
! 2) break;;
! esac
! done
case $result in
0) break;;
2) break;;
esac
done
Index: src/test/regress/resultmap
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/resultmap,v
retrieving revision 1.79
diff -u -c -r1.79 resultmap
*** src/test/regress/resultmap 23 Dec 2004 03:49:40 - 1.79
--- src/test/regress/resultmap 6 Jan 2005 19:30:52 -
***
*** 9,11
--- 9,12
float8/i.86-pc-cygwin=float8-small-is-zero
int8/.*-qnx=int8-exp-three-digits
int8/i.86-pc-mingw32=int8-exp-three-digits
+ point/arm.*-linux-gnu=point,point-fastfpe
*** /dev/null 2005-01-04 07:18:19.0 +0200
--- src/test/regress/expected/point-fastfpe.out 2005-01-06 19:58:45.0
+0200
***
*** 0
--- 1,225
+ --
+ -- POINT
+ --
+ CREATE TABLE POINT_TBL(f1 point);
+ INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
+ -- bad format points
+ INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
+ ERROR: invalid input syntax for type point: asdfasdf
+ INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
+ INSERT INTO POINT_TBL(f1) VALUES ('(10.0
Re: [HACKERS] CSV arm check failure
Marko Kreen wrote: The unconditional-acceptance thing has to be used with great caution; preferably only for issues that we expect on many platforms (such as locale dependencies). How about the following then: let pg_regress.sh accept multiple choices from resultmap. Good idea. I was thinking along the same lines. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
On Jan 7, 2005, at 4:35, Andrew Dunstan wrote: The buildfarm is a dashboard application - when everything is OK you want it to show all green. If that's not a goal, then some redesign is appropriate. Perhaps buildfarm needs its own test suite, rather than leveraging those in the distribution, although that would be a pity, to say the least. What would you think about setting up a few columns to show the results of the various stages, rather than just the single result? Each row might get a little long, but then you can easily see if the other stages (beyond the first problem) work as well. I've been trying to think of a way to shorten the system information, but haven't thought of anything wonderful yet. Best, Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] CSV arm check failure
ARM platform fails the point test see below. parallel group (13 tests): text name char boolean varchar oid int8 int2 float4 int4 float8 bit numeric 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 test strings ... ok test numerology ... ok parallel group (20 tests): lseg point box path circle polygon time timetz comments reltime interval tinterval abstime inet date timestamp timestamptz type_sanity oidjoins opr_sanity point... FAILED lseg ... 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 comments ... ok oidjoins ... ok type_sanity ... ok opr_sanity ... ok test geometry ... ok test horology ... ok test insert ... ok test create_function_1... ok test create_type ... ok test create_table ... ok test create_function_2... ok test copy ... ok parallel group (7 tests): create_aggregate create_operator triggers vacuum constraints inherit create_misc constraints ... ok triggers ... ok create_misc ... ok create_aggregate ... ok create_operator ... ok inherit ... ok vacuum ... ok parallel group (2 tests): create_view create_index create_index ... ok create_view ... ok test sanity_check ... ok test errors ... ok test select ... ok parallel group (18 tests): select_distinct_on select_into select_having update select_distinct case select_implicit union namespace random aggregates hash_index arrays transactions btree_index portals join subselect 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 ... ok portals ... ok arrays ... ok btree_index ... ok hash_index ... ok update ... ok namespace... ok test privileges ... ok test misc ... ok parallel group (5 tests): portals_p2 cluster rules foreign_key select_views select_views ... ok portals_p2 ... ok rules... ok foreign_key ... ok cluster ... ok parallel group (14 tests): truncate sequence limit temp copy2 prepare polymorphism conversion domain rowtypes rangefuncs without_oid plpgsql alter_table 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 test stats... ok test tablespace ... ok *** ./expected/point.outTue Jan 4 10:55:16 2005 --- ./results/point.out Tue Jan 4 12:40:50 2005 *** *** 101,107 | (-3,4) |5 | (-10,0)| 10 | (-5,-12) | 13 ! | (10,10)| 14.142135623731 | (5.1,34.5) | 34.8749193547455 (6 rows) --- 101,107 | (-3,4) |5 | (-10,0)| 10 | (-5,-12) | 13 ! | (10,10)| 14.1421356237309 | (5.1,34.5) | 34.8749193547455 (6 rows) *** *** 127,134 | (-5,-12) | (-10,0)| 13 | (-5,-12) | (0,0) | 13 | (0,0) | (-5,-12) | 13 !| (0,0) | (10,10)| 14.142135623731 !| (10,10)| (0,0) |
