Thread: out-of-scope cursor errors
We seem to have a large portion of the buildfarm red from the ECPG tests, presumably due to the recently applied out-of-scope cursor patches. cheers andrew
Andrew Dunstan írta: > > We seem to have a large portion of the buildfarm red from the ECPG > tests, presumably due to the recently applied out-of-scope cursor > patches. > > cheers > > andrew Hi. I know. Patches were already posted for that, waiting for Michael to review and apply it. Look at the commitfest page. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote: > I know. Patches were already posted for that, > waiting for Michael to review and apply it. Just came back from another trip. Patch works on my system, so I committed it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes írta: > On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote: > >> I know. Patches were already posted for that, >> waiting for Michael to review and apply it. >> > > Just came back from another trip. Patch works on my system, so I committed it. > > Michael > Thanks. Hopefully that will make the buildfarm green from this problem. As you might have noticed, the fix you just committed deleted the test for NaN in the outofscope.pgc regression test, which I tried to fix separately. The buildfarm revealed a problem with NaN/Inf handling, like: - Windows (and mybe others) don't accept "NaN" in strtod() - different UNIX(-like) platforms write out different strings in printf() for a double variable storing. NaN. E.g.: Linux:"nan", Solaris: "NaN", AIX: "NaNQ" Can you also review the NaN/Infinity patch, too? This fix uses the same methods as the backend, i.e. looking for special strings and attempt to handle them in a portable way. There is one possible problem regarding NaNs and risnull()/rsetnull(): I had to introduce a new symbol (NUMERIC_NULL) for handling NULL inline in the numeric value itself. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Boszormenyi Zoltan írta: > - different UNIX(-like) platforms write out different strings in printf() > for a double variable storing. NaN. E.g.: Linux: "nan", > Solaris: "NaN", AIX: "NaNQ" > After I sent it and reread my mail, I realized that my fix wouldn't be enough because of the above: ECPG uses sprintf() for float and double, and just like in the backend, a common code to send "NaN" and +/- "Infinity" to the server is needed. New patch is attached. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
On Sat, Jan 30, 2010 at 11:09:34AM +0100, Boszormenyi Zoltan wrote: > After I sent it and reread my mail, I realized that my fix > wouldn't be enough because of the above: ECPG uses sprintf() > for float and double, and just like in the backend, a common > code to send "NaN" and +/- "Infinity" to the server is needed. > New patch is attached. Does it work for you? I get regression test failures. Haven't looked into the function yet though. *** /home/michael/technik/sources/archive/postgresql/pgsql/src/interfaces/ecpg.nan/test/expected/pgtypeslib-nan_test.stderr 2010-02-02 14:10:30.000000000 +0100 --- /home/michael/technik/sources/archive/postgresql/pgsql/src/interfaces/ecpg.nan/test/results/pgtypeslib-nan_test.stderr 2010-02-02 15:11:17.000000000 +0100 *************** *** 38,44 **** [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: free_params on line 39: parameter 1 = 1 [NO_PID]: sqlca:code: 0, state: 00000 ! [NO_PID]: free_params on line 39: parameter 2 = nan [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_execute on line39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 00000 --- 38,44 ---- [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: free_params on line 39: parameter 1 = 1 [NO_PID]: sqlca:code: 0, state: 00000 ! [NO_PID]: free_params on line 39: parameter 2 = NaN [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_execute on line39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 00000 *************** *** 70,76 **** [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: free_params on line 39: parameter 1 = 2 [NO_PID]: sqlca:code: 0, state: 00000 ! [NO_PID]: free_params on line 39: parameter 2 = inf [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_execute on line39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 00000 --- 70,76 ---- [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: free_params on line 39: parameter 1 = 2 [NO_PID]: sqlca:code: 0, state: 00000 ! [NO_PID]: free_params on line 39: parameter 2 = Infinity [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_executeon line 39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 00000 *************** *** 102,108 **** [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: free_params on line 39: parameter 1 = 3 [NO_PID]: sqlca:code: 0, state: 00000 ! [NO_PID]: free_params on line 39: parameter 2 = -inf [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_execute on line39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 00000 --- 102,108 ---- [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: free_params on line 39: parameter 1 = 3 [NO_PID]: sqlca:code: 0, state: 00000 ! [NO_PID]: free_params on line 39: parameter 2 = -Infinity [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_executeon line 39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 00000 ====================================================================== Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes írta:
> On Sat, Jan 30, 2010 at 11:09:34AM +0100, Boszormenyi Zoltan wrote:
>
>> After I sent it and reread my mail, I realized that my fix
>> wouldn't be enough because of the above: ECPG uses sprintf()
>> for float and double, and just like in the backend, a common
>> code to send "NaN" and +/- "Infinity" to the server is needed.
>> New patch is attached.
>>
>
> Does it work for you? I get regression test failures. Haven't looked into the
> function yet though.
>
Arggg. I didn't update the regression test's stderr.
Actually, I didn't do "make install" before running "make check"
and the target directory had the libraries with my previous changeset.
The diff you quoted reflects the last change. Result of
double d; /* contains NaN or +/- INF */
printf("%lf", d);
is platform-dependent, the new string is
"fixed" across all platforms.
Here's the new patch with the updated regression test.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
Attachment
On Tue, Feb 02, 2010 at 03:34:24PM +0100, Boszormenyi Zoltan wrote: > Here's the new patch with the updated regression test. Committed. Thanks a lot. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes írta: > On Tue, Feb 02, 2010 at 03:34:24PM +0100, Boszormenyi Zoltan wrote: > >> Here's the new patch with the updated regression test. >> > > Committed. Thanks a lot. > > Michael > Tom Lane committed a fix for Windows, there was a missing #include <float.h> in execute.c, but there is another problem on Windows, which I can't fix since I don't have a Windows build system. The linker also complains about missing _isnan(). Can someone help? The equivalent of "-lm" is needed for the cl linker command. Also, another oversight needs fixing on my part, for which the patch is atttached. The INSERT statement in nan_test.pgc contains platform dependent strings, "inf" instead of "infinity". Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
On Wed, Feb 03, 2010 at 10:59:57AM +0100, Boszormenyi Zoltan wrote: > Also, another oversight needs fixing on my part, for which > the patch is atttached. The INSERT statement in nan_test.pgc > contains platform dependent strings, "inf" instead of "infinity". Committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Hi, I added the #include <float.h> to the nan_test.pgc in the hope it fixes the Windows machines in the buildfarm. The patch also contains cleanups in the outofscope and sqlda regression tests so they do #include <pgtypes_numeric.h> instead of exec sql include pgtypes_numeric.h; The results of these two regression tests were affected when I modified this particular header because of this. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
On Thu, Feb 04, 2010 at 03:55:06PM +0100, Boszormenyi Zoltan wrote: > I added the #include <float.h> to the nan_test.pgc in the hope > it fixes the Windows machines in the buildfarm. I already commited this earlier today after looking at the problem myself. But of course I'm also just hoping as I do not have a Windows build system either. So could you please re-diff? > The patch also contains cleanups in the outofscope and sqlda > regression tests so they do > #include <pgtypes_numeric.h> > instead of > exec sql include pgtypes_numeric.h; Is there a reason for this? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Hi, buildfarm member "pika" fails the NaN test. Does FreeBSD/MIPS really return true for isinf(NaN)? Anyway, the attached patch tries to fix the test case by testing isnan() first and doesn't check isinf() if isnan() returned true. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
Boszormenyi Zoltan írta: > Hi, > > buildfarm member "pika" fails the NaN test. > Does FreeBSD/MIPS really return true for isinf(NaN)? > Anyway, the attached patch tries to fix the test case > by testing isnan() first and doesn't check isinf() > if isnan() returned true. > I lied in the patch name, it wasn't a context diff. Also, the same remedy seems to be needed in ecpglib/execute.c, too. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
On Tue, Feb 16, 2010 at 12:21:34PM +0100, Boszormenyi Zoltan wrote: > > Does FreeBSD/MIPS really return true for isinf(NaN)? Actually it's a netbsd beta version, so maybe there's a bug in their libc. But anyway, the patch doesn't seem to hurt, so I committed it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes írta: > On Tue, Feb 16, 2010 at 12:21:34PM +0100, Boszormenyi Zoltan wrote: > >>> Does FreeBSD/MIPS really return true for isinf(NaN)? >>> > > Actually it's a netbsd beta version, so maybe there's a bug in their libc. > I realized my typo after sending my mail. Sorry if I offended anyone calling NetBSD FreeBSD. :-) > But anyway, the patch doesn't seem to hurt, so I committed it. > Thanks. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
> I realized my typo after sending my mail. Sorry if I offended anyone > calling NetBSD FreeBSD. :-) I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: > I was trying to stress the *beta* status. Maybe someone into NetBSD might be > interested in reporting this as a bug. At least it behaves different to all > other archs we have. Hmm, it seems the patch didn't work. Back to the drawing board. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes írta: > On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: > >> I was trying to stress the *beta* status. Maybe someone into NetBSD might be >> interested in reporting this as a bug. At least it behaves different to all >> other archs we have. >> > > Hmm, it seems the patch didn't work. Back to the drawing board. > I hope the amd64 version of NetBSD 5.0.2 behaves similarly, I can only try it as a VM guest... -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Boszormenyi Zoltan írta: > Michael Meskes írta: > >> On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: >> >> >>> I was trying to stress the *beta* status. Maybe someone into NetBSD might be >>> interested in reporting this as a bug. At least it behaves different to all >>> other archs we have. >>> >>> >> Hmm, it seems the patch didn't work. Back to the drawing board. >> >> > > I hope the amd64 version of NetBSD 5.0.2 behaves similarly, > I can only try it as a VM guest... > NetBSD 5.0.2/x86_64 passed all both the main and the ECPG "make check" tests. The BETA might have had a bug or NetBSD/MIPS has some quirks I can't solve. Now what? On a sidenote, this machine fails for the 8.4 STABLE tree, too, in the main "make check"... Is this buildfarm member for detecting bugs in the already obsolete NetBSD 5.0 BETA, or what? The final 5.0 and two bugfix releases are already out for a while. The owner of that particular machine should upgrade. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > Is this buildfarm member for detecting bugs in the already > obsolete NetBSD 5.0 BETA, or what? The final 5.0 and > two bugfix releases are already out for a while. The owner > of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in "core") which tests for NaN and Infinity, which pass. So either those tests are insufficient, orthe code does something different there. Anything you want me to try ? Regards, Rémi Zara
Rémi Zara írta: > Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > >> Is this buildfarm member for detecting bugs in the already >> obsolete NetBSD 5.0 BETA, or what? The final 5.0 and >> two bugfix releases are already out for a while. The owner >> of that particular machine should upgrade. >> > > > I upgraded pika to NetBSD 5.0.2, Thanks very much for that. > and the problem is still there. > :-( > There are some tests (in "core") which tests for NaN and Infinity, which pass. So either those tests are insufficient,or the code does something different there. > Anything you want me to try ? > Here's the attached test code. Compile it with gcc -Wall -o nantest nantest.c -lm and run it. It tests NAN anf INFINITY values with isinf() and isnan(). The expected output is: ================== $ ./nantest computed NAN 1 0 computed INFINITY 0 1 ================== Instead of "computed", NetBSD/x86-64 prints "defined" but the test results are the same as under Linux/x86-64. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit : > > Here's the attached test code. Compile it with > > gcc -Wall -o nantest nantest.c -lm > > and run it. It tests NAN anf INFINITY values with isinf() and isnan(). > The expected output is: > > ================== > $ ./nantest > computed NAN > 1 0 > computed INFINITY > 0 1 > ================== > > Instead of "computed", NetBSD/x86-64 prints "defined" > but the test results are the same as under Linux/x86-64. > Here it is : -bash-4.1$ gcc -Wall -o nantest nantest.c -lm -bash-4.1$ ./nantest defined NAN 0 1 defined INFINITY 0 1 Ok. So, on NetBSD/mips (#ifdef __NetBSD__ && __mips__), isnan(NAN) is true, isnan((double)NAN) is false, and isnan((double)(0.0/ 0.0)) is true. Regards, Rémi Zara
Rémi Zara írta: > Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit : > >> Here's the attached test code. Compile it with >> >> gcc -Wall -o nantest nantest.c -lm >> >> and run it. It tests NAN anf INFINITY values with isinf() and isnan(). >> The expected output is: >> >> ================== >> $ ./nantest >> computed NAN >> 1 0 >> computed INFINITY >> 0 1 >> ================== >> >> Instead of "computed", NetBSD/x86-64 prints "defined" >> but the test results are the same as under Linux/x86-64. >> >> > > Here it is : > First, thanks for running it. > -bash-4.1$ gcc -Wall -o nantest nantest.c -lm > -bash-4.1$ ./nantest > defined NAN > 0 1 > So: isnan((double)NAN) == false, isinf((double)NAN) == true? No wonder this causes a little problem. > defined INFINITY > 0 1 > > Ok. So, on NetBSD/mips (#ifdef __NetBSD__ && __mips__), isnan(NAN) is true, isnan((double)NAN) is false, and isnan((double)(0.0/ 0.0)) is true. > > Regards, > Rémi Zara > NAN on NetBSD/x86-64 is defined as: extern const union __float_u __nanf; #define NAN __nanf.__val I would guess that it's similar on mips. Is is possible that NetBSD/mips has a conversion bug? What I don't get is that the code I used in ECPG and in this test code is the same as in src/backend/utils/adt/float.c. E.g.: float8in sees "NaN" -> value will be (double)NAN float8out sees isnan(value) -> outputs "NaN" string Can someone shed some light on why the backend doesn't get the problem as above? :-( As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division produces NaN. How about doing it explicitely in ECPG? Rémi: please, run this code to confirm the above? Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit : > > NAN on NetBSD/x86-64 is defined as: > > extern const union __float_u __nanf; > #define NAN __nanf.__val > Same here: math.h:extern const union __float_u __nanf; math.h:#define NAN __nanf.__val > I would guess that it's similar on mips. Is is possible that > NetBSD/mips has a conversion bug? > > What I don't get is that the code I used in ECPG and in this > test code is the same as in src/backend/utils/adt/float.c. E.g.: > float8in sees "NaN" -> value will be (double)NAN > float8out sees isnan(value) -> outputs "NaN" string > > Can someone shed some light on why the backend > doesn't get the problem as above? :-( > > As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. > Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division > produces NaN. How about doing it explicitely in ECPG? > > Rémi: please, run this code to confirm the above? > bash-4.1$ gcc -Wall -o nantest1 nantest1.c -lm bash-4.1$ ./nantest1 computed NAN 1 0 defined INFINITY 0 1 Regards, Rémi Zara
I wrote: > As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. > Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division > produces NaN. How about doing it explicitely in ECPG? > I came up with three patches, they are attached. Can you try whether the first patch (missing float.h from data.c) solves the problem? And together with the 2nd one? In that patch I fixed the order of float.h and math.h in nan_test.pgc, which is the opposite of the order found in e.g. backend/utils/adt/float.c. The 3rd patch is explicit about NetBSD/mips but it doesn't feel right. They are working on Linux/x86-64 and NetBSD/x86-64. Can you try the combinations below on "pika" outside the buildfarm whether they still fail the ECPG make check? - patch 1 by itself (12a) - patch 1+2 (12a + 12-regr) - patch 3 with/without 1+2 Sorry to give you work, but we don't have a mips machine. Thanks in advance, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Attachment
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > > > Is this buildfarm member for detecting bugs in the already > obsolete NetBSD 5.0 BETA, or what? The final 5.0 and > two bugfix releases are already out for a while. The owner > of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in "core") which tests for NaN and Infinity, which pass. So either those tests are insufficient, orthe code does something different there. Anything you want me to try ? Regards, Rémi Zara
Boszormenyi Zoltan <zb@cybertec.at> writes:
> Can you try whether the first patch (missing float.h from data.c)
> solves the problem? And together with the 2nd one? In that
> patch I fixed the order of float.h and math.h in nan_test.pgc,
> which is the opposite of the order found in e.g. backend/utils/adt/float.c.
> The 3rd patch is explicit about NetBSD/mips but it doesn't feel right.
The third patch is surely wrong. We don't need to do that in the
backend's instance of get_float8_nan, so ecpglib shouldn't need it
either.
I suspect that the ultimate cause of this is either one of the header
inclusion inconsistencies you found, or something associated with
not pulling in all the stuff that postgres.h does. port/netbsd.h
is empty though, so it's not immediately clear what might be missing.
regards, tom lane
Tom Lane írta: > Boszormenyi Zoltan <zb@cybertec.at> writes: > >> Can you try whether the first patch (missing float.h from data.c) >> solves the problem? And together with the 2nd one? In that >> patch I fixed the order of float.h and math.h in nan_test.pgc, >> which is the opposite of the order found in e.g. backend/utils/adt/float.c. >> > > >> The 3rd patch is explicit about NetBSD/mips but it doesn't feel right. >> > > The third patch is surely wrong. We don't need to do that in the > backend's instance of get_float8_nan, so ecpglib shouldn't need it > either. > > I suspect that the ultimate cause of this is either one of the header > inclusion inconsistencies you found, or something associated with > not pulling in all the stuff that postgres.h does. port/netbsd.h > is empty though, so it's not immediately clear what might be missing. > ecpglib/data.c includes "postgres_fe.h", so it should be pulling everything that's relevant from port/*, right? Michael, can we try to install the first two patches? They wouldn't hurt. Thanks in advance, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
Le 26 févr. 2010 à 12:12, Boszormenyi Zoltan a écrit :
>
> ecpglib/data.c includes "postgres_fe.h", so it should be pulling
> everything that's relevant from port/*, right?
>
> Michael, can we try to install the first two patches?
> They wouldn't hurt.
>
I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because
strtod("NaN",endptr) works. (isnan(strtod("NaN", endptr)) is true).
I should also note that isnan((double)nan("")) is true (works).
I will also report to NetBSD that isnan((double)NAN) does not work on mips.
Regards,
Rémi Zara
On Fri, Feb 26, 2010 at 12:12:10PM +0100, Boszormenyi Zoltan wrote: > Michael, can we try to install the first two patches? If I understood the rest of the thread correctly this is not needed anymore, right? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Rémi Zara <remi_zara@mac.com> writes:
> I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because
strtod("NaN",endptr) works. (isnan(strtod("NaN", endptr)) is true).
Hmm. So what do you get fromSELECT 'nan'::numeric::float8;
on that machine? That should exercise the backend's version of
get_float8_nan().
regards, tom lane
Michael Meskes <meskes@postgresql.org> writes:
> On Fri, Feb 26, 2010 at 12:12:10PM +0100, Boszormenyi Zoltan wrote:
>> Michael, can we try to install the first two patches?
> If I understood the rest of the thread correctly this is not needed anymore,
> right?
I think it would be a good idea, just to have all that code using
identical #includes. R�mi's problem may be a platform bug rather
than something we can fix ourselves, but I think that making sure that
ecpg uses the exact same coding that's been proven in the backend
will forestall problems on other platforms.
regards, tom lane
Le 26 févr. 2010 à 17:11, Tom Lane a écrit :
> Rémi Zara <remi_zara@mac.com> writes:
>> I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because
strtod("NaN",endptr) works. (isnan(strtod("NaN", endptr)) is true).
>
> Hmm. So what do you get from
> SELECT 'nan'::numeric::float8;
> on that machine? That should exercise the backend's version of
> get_float8_nan().
>
regression=# select 'nan'::numeric::float8; float8
----------Infinity
(1 row)
So it is indeed the same behavior. Maybe that should be added to the regression tests.
So what's the best way to workaround the bug in NetBSD/mips ? (nan(""), (0.0/0.0), strtod("nan", null) ?)
Regards,
Rémi Zara
Rémi Zara <remi_zara@mac.com> writes:
> Le 26 f�vr. 2010 � 17:11, Tom Lane a �crit :
>> Hmm. So what do you get from
>> SELECT 'nan'::numeric::float8;
> regression=# select 'nan'::numeric::float8;
> float8
> ----------
> Infinity
> (1 row)
> So it is indeed the same behavior.
Yeah. So what it boils down to is that the platform has a NAN constant
but casting it to double produces the wrong thing. There's no doubt
that that's a bug in the floating-point support. You did say you'd
submitted it to the NetBSD folk right?
BTW, what about the float4 case, 'nan'::numeric::float4 ?
> Maybe that should be added to the regression tests.
Perhaps. A lot of this stuff was never stress-tested in the past
because when it was put in, it was a crap shoot whether NaN (or Inf)
really worked on most platforms. Our attitude was "if it works for you,
great, but we're not going to sweat about it if it doesn't". I'm not
sure whether full IEEE float support has gotten sufficiently universal
to justify expecting more. I guess we could try it and see how many
other buildfarm members fail.
> So what's the best way to workaround the bug in NetBSD/mips ?
I don't think it's our bug to fix.
regards, tom lane
Le 27 févr. 2010 à 17:57, Tom Lane a écrit : > Rémi Zara <remi_zara@mac.com> writes: >> Le 26 févr. 2010 à 17:11, Tom Lane a écrit : >>> Hmm. So what do you get from >>> SELECT 'nan'::numeric::float8; > >> regression=# select 'nan'::numeric::float8; >> float8 >> ---------- >> Infinity >> (1 row) > >> So it is indeed the same behavior. > > Yeah. So what it boils down to is that the platform has a NAN constant > but casting it to double produces the wrong thing. There's no doubt > that that's a bug in the floating-point support. You did say you'd > submitted it to the NetBSD folk right? > I submitted it. > BTW, what about the float4 case, 'nan'::numeric::float4 ? That works OK. > >> Maybe that should be added to the regression tests. > > Perhaps. A lot of this stuff was never stress-tested in the past > because when it was put in, it was a crap shoot whether NaN (or Inf) > really worked on most platforms. Our attitude was "if it works for you, > great, but we're not going to sweat about it if it doesn't". I'm not > sure whether full IEEE float support has gotten sufficiently universal > to justify expecting more. I guess we could try it and see how many > other buildfarm members fail. > >> So what's the best way to workaround the bug in NetBSD/mips ? > > I don't think it's our bug to fix. > It would mean retiring pika until/if the bug is fixed... :-( Regards, Rémi Zara
Rémi Zara <remi_zara@mac.com> writes:
> Le 27 f�vr. 2010 � 17:57, Tom Lane a �crit :
>> I don't think it's our bug to fix.
> It would mean retiring pika until/if the bug is fixed... :-(
Grumble ... well, I suppose we've put in worse platform-specific hacks
elsewhere. At least this is pretty localized.
regards, tom lane
On Fri, Feb 26, 2010 at 11:14:01AM -0500, Tom Lane wrote: > I think it would be a good idea, just to have all that code using > identical #includes. R�mi's problem may be a platform bug rather Sounds reasonable, done. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL