Martin Pitt <martin@piware.de> writes: > The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions > up to 8.2 worked fine). We redid some of the float error handling for 8.3, in hopes of getting closer to the IEEE standard behavior for NaNs and infinities and so on. I guess that isn't working on your Alpha. I have a vague recollection that Alphas use non-IEEE floats so maybe this is not too surprising. Can you grant one of us access to the machine to work on it? Or poke into it yourself? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

=?ISO-8859-1?Q?=22Jos=E9_Luis_Rivero_=28yoswink=29=22?= <yoswink@gentoo.org> writes: > Since Debian is having some problems with its alpha development machine, > the Gentoo/Alpha port is happy to offer some help with this problem. > We can provide with shell account access (or even a chroot) in our > development machine (AlphaServer ES40) for debugging this PostgreSQL > bug. If it only happens on Debian, I could create a debian chroot for > testing. I'm guessing that it's specific to Alpha (and maybe glibc) but not any particular Linux distro. So let's try Gentoo first, and then Martin can check if the fix works for Debian. If you could set me up a shell account accessible by ssh, I should have time to poke at this tomorrow. I don't need root access but will need all the usual C development tools (gcc, gdb, etc). Thanks for helping! regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Steve Langasek <vorlon@debian.org> writes: > It may be specific to particular versions of glibc and the kernel. At least > one of the test regressions is actually due to the bug described in > <http://lists.debian.org/debian-alpha/2007/10/msg00014.html>; I haven't dug > into the rest of the failures further at this point. Thanks for the tip about that bug. Using the gentoo project's kindly-lent Alpha, I see that the failure in our float8 regression test is indeed explained by floor() doing the wrong thing. The case that fails is regression=# select (-34.84)::float8 ^ '1e200'; ERROR: 2201F: invalid argument for power function LOCATION: dpow, float.c:1337 where we are expecting to get "value out of range: overflow". Instead this test is failing: /* * The SQL spec requires that we emit a particular SQLSTATE error code for * certain error conditions. */ if ((arg1 == 0 && arg2 < 0) || (arg1 < 0 && floor(arg2) != arg2)) ereport(ERROR, (errcode(ERRCODE_INVALID_ARGUMENT_FOR_POWER_FUNCTION), errmsg("invalid argument for power function"))); and indeed regression=# select floor(1e200::float8) - 1e200::float8; ?column? ------------------------ -1.69964157701365e+184 (1 row) so it seems floor(3m) is off by one in the last place. > But if it can be reproduced on other distros as well, all the better. All the other diffs that Martin showed are divide-by-zero failures, and I do not see any of them on Gentoo's machine. I think that this must be a compiler bug. The first example in his diffs is just "select 1/0", which executes this code: int32 arg1 = PG_GETARG_INT32(0); int32 arg2 = PG_GETARG_INT32(1); int32 result; if (arg2 == 0) ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg("division by zero"))); result = arg1 / arg2; It looks to me like Debian's compiler must be allowing the division instruction to be speculatively executed before the if-test branch is taken. Perhaps it is supposing that this is OK because control will return from ereport(), when in fact it will not (the routine throws a longjmp). Since we've not seen such behavior on any other platform, however, I suspect this is just a bug and not intentional. FWIW the Gentoo machine is running $ gcc -v Using built-in specs. Target: alpha-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/alpha-unknown-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include/g++-v4 --host=alpha-unknown-linux-gnu --build=alpha-unknown-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) Bottom line is that I see nothing here that the Postgres project can fix --- these are library and compiler bugs. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Martin Pitt <martin@piware.de> writes: > The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions > up to 8.2 worked fine). Apparently there is some disagreement about > how to report divisions by zero: BTW, having now looked closely at the diffs, the problems do not seem to be anywhere near the code we changed for 8.3. So I think the real issue is that your compiler and glibc changed under you. Could you perhaps retest 8.2 with the current toolchain and confirm that it fails too? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Pedro Gimeno <pgsql-001@personal.formauri.es> writes: > Tom Lane wrote: >> BTW, having now looked closely at the diffs, the problems do not seem >> be anywhere near the code we changed for 8.3. So I think the real >> issue is that your compiler and glibc changed under you. Could you >> perhaps retest 8.2 with the current toolchain and confirm that it >> fails too? > I'm not in the Debian team but may this help? > http://buildd.debian.org/build.php?arch=alpha&pkg=postgresql-8.2 Yeah, that seems to confirm that it is a tools problem rather than anything we did to 8.3 ... and moreover that the breakage went in sometime between Jun 23 and Aug 17. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate