Re: CSV arm check failure

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

In response to

Responses

Browse pgsql-hackers by date

  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