Bruce,

That's what I would have half expected too but am I actually using
any floating point arithmetic?

The function called is int4div() which simply does a, return (arg1/arg2),
so I would have expected integer arithmetic.

If I cast to float I get:-

postgres=> select 1::float8/0::float8;
ERROR:  float8div: divide by zero error
postgres=>

The error coming courtesy of :-

        if (*arg2 == 0.0)
                elog(ERROR, "float8div: divide by zero error");
 
in backend/utils/adt/float.c:604

I'm still puzzled but lean towards a signal problem too.

I do get FP exceptions as there's one in the float8.out regression
test, where there shouldn't be one!!

QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
ERROR:  floating point exception! The last floating point operation either 
exceeded legal ranges or was a divide by zero
QUERY: SELECT '' AS bad, f.f1 / '0.0' from FLOAT8_TBL f;
ERROR:  float8div: divide by zero error       


Keith.


Bruce Momjian <maillist@candle.pha.pa.us>
> > 
> > Hi All,
> > 
> > In the latest CVS I can get the backend to terminate quite
> > easily with a divide by 0.
> > 
> > postgres=> select 1/0;
> > pqReadData() -- backend closed the channel unexpectedly.
> >         This probably means the backend terminated abnormally before or 
while 
> > processing the request.
> > We have lost the connection to the backend, so further processing is 
impossible. 
> >  Terminating.
> > [postgres@sparclinux pgsql]$ 
> > 
> > A bt on the core shows:-
> > 
> > I don't know if this is recently introduced behaviour or if
> > it's platform dependant. I can't recall trying this before
> > so maybe it's always happened on S/Linux.
> > 
> > My immediate thought is to include a check for divide by 0
> > in the intXXdiv() functions and do something like an elog(WARN,...)
> > 
> > Firstly, what do other people get on their platform?
> 
> I get:
> 
> ttest=> select 1/0;
> ERROR:  floating point exception! The last floating point operation
> either exceeded legal ranges or was a divide by zero
> 
> so it looks like the signal.  Check these lines:
> 
> #$ gid FloatExceptionHandler
> backend/postmaster/postmaster.c:1247:   pqsignal(SIGFPE, 
FloatExceptionHandler);
> backend/tcop/postgres.c:772: FloatExceptionHandler(SIGNAL_ARGS)
> include/tcop/tcopprot.h:37: extern void FloatExceptionHandler(SIGNAL_ARGS);
> 


Mon, 22 Jun 1998 23:52:26 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Re: [HACKERS] Divide by zero error on SPARC/Linux.
> 
> Bruce,
> 
> That's what I would have half expected too but am I actually using
> any floating point arithmetic?
> 
> The function called is int4div() which simply does a, return (arg1/arg2),
> so I would have expected integer arithmetic.
> 
> If I cast to float I get:-
> 
> postgres=> select 1::float8/0::float8;
> ERROR:  float8div: divide by zero error
> postgres=>

I recommend you put debugs around where it is crashing, and the
reproduce it in a C program, with the same signal() call to catch it,
and see if it works.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tue, 23 Jun 1998 00:16:52 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Divide by zero error on SPARC/Linux.