From: | Marko Kreen <marko(at)l-t(dot)ee> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Jim Buttafuoco <jim(at)contactbda(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CSV arm check failure |
Date: | 2005-01-06 18:18:58 |
Message-ID: | 20050106181858.GA9281@l-t.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
point-fastfpe.diff | text/plain | 8.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-01-06 19:05:17 | Re: CSV arm check failure |
Previous Message | Andrew Dunstan | 2005-01-06 17:32:12 | Re: CSV arm check failure |