Thread: division by zero
I admit, I suck at math, but I really thought postgres would ERROR on
this:
foo=# select 1/0;
?column?
----------
0
(1 row)
More surprising is that this does ERROR:
foo=# select 1/0.0;
ERROR: division by zero on numeric
Is this a bug, or do I need to go back to high school algebra? "Both"
is an acceptable answer. :)
eric
I think this caused by floating point signals being reported by the OS, while integer operations don't have signals. I suppose we could catch the divide by zero easily. Folks? --------------------------------------------------------------------------- Eric B.Ridge wrote: > I admit, I suck at math, but I really thought postgres would ERROR on > this: > > foo=# select 1/0; > ?column? > ---------- > 0 > (1 row) > > More surprising is that this does ERROR: > foo=# select 1/0.0; > ERROR: division by zero on numeric > > Is this a bug, or do I need to go back to high school algebra? "Both" > is an acceptable answer. :) > > eric > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
"Eric B.Ridge" <ebr@tcdi.com> writes:
> I admit, I suck at math, but I really thought postgres would ERROR on
> this:
> foo=# select 1/0;
There's something wrong with your platform, I think. I get an error on
both HPUX and Red Hat Linux. What platform is this? and what PG
version?
z=# select 1/0;
ERROR: floating point exception! The last floating point operation either exceeded legal ranges or was a divide by
zero
z=#
regards, tom lane
On Friday, March 7, 2003, at 02:50 PM, Tom Lane wrote:
> "Eric B.Ridge" <ebr@tcdi.com> writes:
>> I admit, I suck at math, but I really thought postgres would ERROR on
>> this:
>
>> foo=# select 1/0;
>
> There's something wrong with your platform, I think. I get an error on
> both HPUX and Red Hat Linux. What platform is this? and what PG
> version?
I'm sorry. I know better.
% uname -a
Darwin foo.local. 6.4 Darwin Kernel Version 6.4: Wed Jan 29 18:50:42
PST 2003; root:xnu/xnu-344.26.obj~1/RELEASE_PPC Power Macintosh powerpc
Which translates to Mac OS X 10.2.4 (6I32)
foo=# select version();
version
------------------------------------------------------------------------
--------------------------
PostgreSQL 7.3.2 on powerpc-apple-darwin6.4, compiled by GCC gcc (GCC)
3.1 20020420 (prerelease)
select 1/0; fails as expected on my x86 Linux box, so yer right, it's
just my little Mac. "I switched because Mac's can divide by zero."
eric
> z=# select 1/0;
> ERROR: floating point exception! The last floating point operation
> either exceeded legal ranges or was a divide by zero
> z=#
>
> regards, tom lane
"Eric B. Ridge" <ebr@tcdi.com> writes:
> select 1/0; fails as expected on my x86 Linux box, so yer right, it's
> just my little Mac. "I switched because Mac's can divide by zero."
Mph. I have a Mac handy, will look into this.
Can anyone confirm whether the error shows up on other BSD-derived
platforms?
regards, tom lane
En un mensaje anterior, Tom Lane escribió:
> Can anyone confirm whether the error shows up on other BSD-derived
> platforms?
FreeBSD 4.7-RELEASE-p7
db=# SELECT version();
version
---------------------------------------------------------------------
PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4
(1 row)
db=# SELECT 1/0;
ERROR: floating point exception! The last floating point operation either
exceeded legal ranges or was a divide by zero
Regards.
mcs=# select 1/0;
ERROR: floating point exception! The last floating point operation either
exceeded legal ranges or was a divide by zero
mcs=# select version();
version
---------------------------------------------------------------------
PostgreSQL 7.2.1 on i386-portbld-freebsd4.5, compiled by GCC 2.95.3
(1 row)
-----Original Message-----
From: Fernando Schapachnik [mailto:fernando@mecon.gov.ar]
Sent: Friday, March 07, 2003 3:09 PM
To: Tom Lane
Cc: Eric B. Ridge; pgsql-general@postgresql.org
Subject: Re: [GENERAL] division by zero
En un mensaje anterior, Tom Lane escribió:
> Can anyone confirm whether the error shows up on other BSD-derived
> platforms?
FreeBSD 4.7-RELEASE-p7
db=# SELECT version();
version
---------------------------------------------------------------------
PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4
(1 row)
db=# SELECT 1/0;
ERROR: floating point exception! The last floating point operation either
exceeded legal ranges or was a divide by zero
Regards.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Error on BSD/OS too. I should have checked that. --------------------------------------------------------------------------- Pam Wampler wrote: > mcs=# select 1/0; > ERROR: floating point exception! The last floating point operation either > exceeded legal ranges or was a divide by zero > mcs=# select version(); > version > --------------------------------------------------------------------- > PostgreSQL 7.2.1 on i386-portbld-freebsd4.5, compiled by GCC 2.95.3 > (1 row) > > > > -----Original Message----- > From: Fernando Schapachnik [mailto:fernando@mecon.gov.ar] > Sent: Friday, March 07, 2003 3:09 PM > To: Tom Lane > Cc: Eric B. Ridge; pgsql-general@postgresql.org > Subject: Re: [GENERAL] division by zero > > > En un mensaje anterior, Tom Lane escribi?: > > Can anyone confirm whether the error shows up on other BSD-derived > > platforms? > > > FreeBSD 4.7-RELEASE-p7 > > db=# SELECT version(); > version > --------------------------------------------------------------------- > PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4 > (1 row) > > db=# SELECT 1/0; > ERROR: floating point exception! The last floating point operation either > exceeded legal ranges or was a divide by zero > > Regards. > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Friday, March 7, 2003, at 03:05 PM, Tom Lane wrote: > "Eric B. Ridge" <ebr@tcdi.com> writes: >> select 1/0; fails as expected on my x86 Linux box, so yer right, it's >> just my little Mac. "I switched because Mac's can divide by zero." > > Mph. I have a Mac handy, will look into this. I doubt this helps, but I just tried on my Mac against 7.2.3 and it still returns zero. eric > > Can anyone confirm whether the error shows up on other BSD-derived > platforms? > > regards, tom lane
fyi, my mac running mac os 10.2.4 and postgres 7.3.1 returns zero also. On Friday, March 7, 2003, at 02:36 PM, Eric B.Ridge wrote: > On Friday, March 7, 2003, at 03:05 PM, Tom Lane wrote: > >> "Eric B. Ridge" <ebr@tcdi.com> writes: >>> select 1/0; fails as expected on my x86 Linux box, so yer right, it's >>> just my little Mac. "I switched because Mac's can divide by zero." >> >> Mph. I have a Mac handy, will look into this. > > I doubt this helps, but I just tried on my Mac against 7.2.3 and it > still returns zero. > > eric > >> >> Can anyone confirm whether the error shows up on other BSD-derived >> platforms? >> >> regards, tom lane > > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
"Eric B. Ridge" <ebr@tcdi.com> writes:
> select 1/0; fails as expected on my x86 Linux box, so yer right, it's
> just my little Mac. "I switched because Mac's can divide by zero."
I checked into this, and indeed OS X 10.2 is behaving funny: integer
divide by zero doesn't raise any signal, it just returns a bogus answer.
They're within their rights to do so according to the ANSI C spec
(wherein division by zero is stated to have undefined behavior).
But since other BSD-derived Unixen all seem to raise SIGFPE, I can't
help wondering if this shouldn't be considered a bug.
I think we have three possible responses:
1. Put explicit tests for zero into the integer division SQL function
routines.
2. Consider this Apple's problem and file a bug report.
3. Both.
I don't care for answer #1 alone, because it would only catch zero
divides in the specific places we put in tests; internal errors would
likely go uncaught. So I think a complaint to Apple is in order.
I'm not sure whether to also put in zero-divide guards. Comments?
regards, tom lane
On Sat, 8 Mar 2003, Tom Lane wrote: > "Eric B. Ridge" <ebr@tcdi.com> writes: > > select 1/0; fails as expected on my x86 Linux box, so yer right, it's > > just my little Mac. "I switched because Mac's can divide by zero." > > I checked into this, and indeed OS X 10.2 is behaving funny: integer > divide by zero doesn't raise any signal, it just returns a bogus answer. > They're within their rights to do so according to the ANSI C spec > (wherein division by zero is stated to have undefined behavior). > But since other BSD-derived Unixen all seem to raise SIGFPE, I can't > help wondering if this shouldn't be considered a bug. > > I think we have three possible responses: > > 1. Put explicit tests for zero into the integer division SQL function > routines. > > 2. Consider this Apple's problem and file a bug report. > > 3. Both. > > I don't care for answer #1 alone, because it would only catch zero > divides in the specific places we put in tests; internal errors would > likely go uncaught. So I think a complaint to Apple is in order. > I'm not sure whether to also put in zero-divide guards. Comments? We probably should put in guards since relying on sane behavior for division by zero is probably unsafe from a portability standpoint. This could hide some internal error on a system that has this problem (since we could otherwise put it into a regression test) but those systems are currently broken if the internal error occurs anyway.