SEO

Hello PostgreSQL developers,

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:

float8.out:
- ERROR: value out of range: overflow
+ ERROR: invalid argument for power function

errors.out:
- ERROR: division by zero
+ ERROR: floating-point exception
+ DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero.

and some more (case, transactions, guc, plpgsql).

The full build log including diffs and initdb/postmaster logs is on
http://experimental.ftbfs.de/fetch.p...ile=log&as=raw

Thank you!

Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHLI+yDecnbV4Fd/IRAp1JAKD+L2BqEuCf2jusMNRFanB20nBV1wCgw+Q1
jtCc+XGofS+Z2yBqNI5TJUY=
=tnMU
-----END PGP SIGNATURE-----

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

Hi,

Tom Lane [2007-11-03 14:27 -0400]:
> 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?

I don't own any alpha machine, but maybe Frank, Steven, or anyone from
the Debian alpha porter list can create a temporary account for you?

> Or poke into it yourself?

There is no developer accessible alpha porter box for Debian
unfortunately.

Thank you,

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sat, Nov 03, 2007 at 06:32:34PM -0400, Martin Pitt wrote:
> Tom Lane [2007-11-03 14:27 -0400]:
> > 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?
>
> I don't own any alpha machine, but maybe Frank, Steven, or anyone from
> the Debian alpha porter list can create a temporary account for you?

I'm not sure how we handle that for our experimental buildds. Admins?

Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Hi *:

Martin Pitt escribió:
> Hi,
>
> Tom Lane [2007-11-03 14:27 -0400]:
>> 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?
>
> I don't own any alpha machine, but maybe Frank, Steven, or anyone from
> the Debian alpha porter list can create a temporary account for you?
>
>> Or poke into it yourself?
>
> There is no developer accessible alpha porter box for Debian
> unfortunately.
>

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.

Gentoo/Alpha Team can be reached by mail: alpha@gentoo.org or by IRC in
Freenode #gentoo-alpha.

Thanks and feel free to ask if you need something more.

--
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Doc Gentoo/Alpha

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

=?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

Hi!

On Tue, 06 Nov 2007, Tom Lane wrote:
> 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).

Just send me a (preferably signed) mail with desired username and
SSH-PubKey.

Regards,
Tobias
--
In the future, everyone will be anonymous for 15 minutes.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, Nov 06, 2007 at 12:52:34PM -0500, Tom Lane wrote:
> =?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.

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.

But if it can be reproduced on other distros as well, all the better.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/

---------------------------(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_FUNCTI ON),
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