Hi,

Can anyone else reproduce this problem?
(Maybe a signal handling problem on S/Linux??)

Using the regression database...

Keith.


regression=> select * from person where age in (38,68);
name   |age|location
-------+---+----------
teresa | 38|(7.7,1.8)
leah   | 68|(0.6,3.37)
liza   | 38|(9.76,6.9)
jenifer| 38|(6.6,23.3)
sumi   | 38|(1.15,0.6)
paula  | 68|(0.5,0.5)
julie  | 68|(3.6,7.2)
belinda| 38|(8.9,1.7)
sandy  | 38|(3.8,0.2)
velma  | 68|(8.8,8.9)
(10 rows)

regression=> create index p_age_idx on person (age);
CREATE
regression=> select * from person where age in (38,68);
ERROR:  floating point exception! The last floating point operation either 
exceeded legal ranges or was a divide by zero
regression=> drop index p_age_idx;
DROP
regression=> select * from person where age in (38,68);
name   |age|location
-------+---+----------
teresa | 38|(7.7,1.8)
leah   | 68|(0.6,3.37)
liza   | 38|(9.76,6.9)
jenifer| 38|(6.6,23.3)
sumi   | 38|(1.15,0.6)
paula  | 68|(0.5,0.5)
julie  | 68|(3.6,7.2)
belinda| 38|(8.9,1.7)
sandy  | 38|(3.8,0.2)
velma  | 68|(8.8,8.9)
(10 rows)

regression=> 

Here's a trace.

Program received signal SIGFPE, Arithmetic exception.
0x931c4 in create_or_index_paths (root=0x1d7d10, rel=0x1efb90, clauses=0x1f9270) 
at orindxpath.c:128
128                                     t_list = lappend(t_list, pathnode);
(gdb) bt
#0  0x931c4 in create_or_index_paths (root=0x1d7d10, rel=0x1efb90, 
clauses=0x1f9270) at orindxpath.c:128
#1  0x8f0fc in find_rel_paths (root=0x1d7d10, rels=0x1f9510) at allpaths.c:130
#2  0x8f06c in find_paths (root=0x1d7d10, rels=0x1f9510) at allpaths.c:77
#3  0x94d48 in subplanner (root=0x1d7d10, flat_tlist=0x1f96f0, qual=0x1f9950) at 
planmain.c:279
#4  0x94c30 in query_planner (root=0x1d7d10, command_type=1, tlist=0x1f43f0, 
qual=0x1f9950) at planmain.c:183
#5  0x953c0 in union_planner (parse=0x1d7d10) at planner.c:151
#6  0x95228 in planner (parse=0x1d7d10) at planner.c:72
#7  0xccf1c in pg_parse_and_plan (query_string=0xefffd1a0 "select * from person 
where age in (38,68);",
    typev=0x0, nargs=0, queryListP=0xefffd09c, dest=Remote, aclOverride=0 
'\000') at postgres.c:626
#8  0xcd040 in pg_exec_query_dest (query_string=0xefffd1a0 "select * from person 
where age in (38,68);",
    dest=Remote, aclOverride=0 '\000') at postgres.c:720
#9  0xccff4 in pg_exec_query (query_string=0xefffd1a0 "select * from person 
where age in (38,68);")
    at postgres.c:697
#10 0xce2e4 in PostgresMain (argc=10, argv=0xeffff268, real_argc=10, 
real_argv=0xeffffd84) at postgres.c:1611
#11 0xb1fcc in DoBackend (port=0x12d800) at postmaster.c:1528
#12 0xb1a44 in BackendStartup (port=0x190c00) at postmaster.c:1299
#13 0xb0ebc in ServerLoop () at postmaster.c:757
#14 0xb0a04 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:563
#15 0x83870 in main (argc=10, argv=0xeffffd84) at main.c:93
(gdb) print t_list
$1 = (List *) 0x0
(gdb) print  pathnode
$2 = (IndexPath *) 0x1ef210
(gdb) print  *pathnode
$3 = {path = {type = T_IndexPath, parent = 0x1efb90, path_cost = 4.0999999, 
pathtype = T_IndexScan,
    p_ordering = {ordtype = MERGE_ORDER, ord = {sortop = 0x0, merge = 0x0}}, 
keys = 0x0, outerjoincost = 0,
    joinid = 0x0, locclauseinfo = 0x0}, indexid = 0x1e5dd0, indexqual = 
0x1e5b90, indexkeys = 0x0}
(gdb)                                                                                                 


Sat, 12 Sep 1998 14:56:39 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Exception in select IN with index
In message <199809121356.OAA21197@mtcc.demon.co.uk>, Keith Parks writes:
> Hi,
> 
> Can anyone else reproduce this problem?
> (Maybe a signal handling problem on S/Linux??)
> 
> Using the regression database...
> 
> Keith.
> 
> 
> regression=> select * from person where age in (38,68);
> name   |age|location
> -------+---+----------
> teresa | 38|(7.7,1.8)
> leah   | 68|(0.6,3.37)
> liza   | 38|(9.76,6.9)
> jenifer| 38|(6.6,23.3)
> sumi   | 38|(1.15,0.6)
> paula  | 68|(0.5,0.5)
> julie  | 68|(3.6,7.2)
> belinda| 38|(8.9,1.7)
> sandy  | 38|(3.8,0.2)
> velma  | 68|(8.8,8.9)
> (10 rows)
> 
> regression=> create index p_age_idx on person (age);
> CREATE
> regression=> select * from person where age in (38,68);
> ERROR:  floating point exception! The last floating point operation either 
> exceeded legal ranges or was a divide by zero
> regression=> drop index p_age_idx;
> DROP
> regression=> select * from person where age in (38,68);
> name   |age|location
> -------+---+----------
> teresa | 38|(7.7,1.8)
> leah   | 68|(0.6,3.37)
> liza   | 38|(9.76,6.9)
> jenifer| 38|(6.6,23.3)
> sumi   | 38|(1.15,0.6)
> paula  | 68|(0.5,0.5)
> julie  | 68|(3.6,7.2)
> belinda| 38|(8.9,1.7)
> sandy  | 38|(3.8,0.2)
> velma  | 68|(8.8,8.9)
> (10 rows)
> 
> regression=> 
> 
> Here's a trace.
> 
> Program received signal SIGFPE, Arithmetic exception.
> 0x931c4 in create_or_index_paths (root=0x1d7d10, rel=0x1efb90, clauses=0x1f9270) 
> at orindxpath.c:128
> 128                                     t_list = lappend(t_list, pathnode);
> (gdb) bt
> #0  0x931c4 in create_or_index_paths (root=0x1d7d10, rel=0x1efb90, 
> clauses=0x1f9270) at orindxpath.c:128
> #1  0x8f0fc in find_rel_paths (root=0x1d7d10, rels=0x1f9510) at allpaths.c:130
> #2  0x8f06c in find_paths (root=0x1d7d10, rels=0x1f9510) at allpaths.c:77
> #3  0x94d48 in subplanner (root=0x1d7d10, flat_tlist=0x1f96f0, qual=0x1f9950) at 
> planmain.c:279
> #4  0x94c30 in query_planner (root=0x1d7d10, command_type=1, tlist=0x1f43f0, 
> qual=0x1f9950) at planmain.c:183
> #5  0x953c0 in union_planner (parse=0x1d7d10) at planner.c:151
> #6  0x95228 in planner (parse=0x1d7d10) at planner.c:72
> #7  0xccf1c in pg_parse_and_plan (query_string=0xefffd1a0 "select * from person 
> where age in (38,68);",
>     typev=0x0, nargs=0, queryListP=0xefffd09c, dest=Remote, aclOverride=0 
> '\000') at postgres.c:626
> #8  0xcd040 in pg_exec_query_dest (query_string=0xefffd1a0 "select * from person 
> where age in (38,68);",
>     dest=Remote, aclOverride=0 '\000') at postgres.c:720
> #9  0xccff4 in pg_exec_query (query_string=0xefffd1a0 "select * from person 
> where age in (38,68);")
>     at postgres.c:697
> #10 0xce2e4 in PostgresMain (argc=10, argv=0xeffff268, real_argc=10, 
> real_argv=0xeffffd84) at postgres.c:1611
> #11 0xb1fcc in DoBackend (port=0x12d800) at postmaster.c:1528
> #12 0xb1a44 in BackendStartup (port=0x190c00) at postmaster.c:1299
> #13 0xb0ebc in ServerLoop () at postmaster.c:757
> #14 0xb0a04 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:563
> #15 0x83870 in main (argc=10, argv=0xeffffd84) at main.c:93
> (gdb) print t_list
> $1 = (List *) 0x0
> (gdb) print  pathnode
> $2 = (IndexPath *) 0x1ef210
> (gdb) print  *pathnode
> $3 = {path = {type = T_IndexPath, parent = 0x1efb90, path_cost = 4.0999999, 
> pathtype = T_IndexScan,
>     p_ordering = {ordtype = MERGE_ORDER, ord = {sortop = 0x0, merge = 0x0}}, 
> keys = 0x0, outerjoincost = 0,
>     joinid = 0x0, locclauseinfo = 0x0}, indexid = 0x1e5dd0, indexqual = 
> 0x1e5b90, indexkeys = 0x0}
> (gdb)                                                                                        
>          
> 
> 

Sorry Keith, It works on my Sparc 20 running S/Linux.  I'm using a cvs copy 
from sometime on Sept 10.  It also works on my solaris 2.6 box (ultra 30).


Tom Szybist
szybist@boxhill.com


Sat, 12 Sep 1998 11:35:46 -0400
"Thomas A. Szybist" <szybist@boxhill.com>
Re: [HACKERS] Exception in select IN with index 
From: Tom Lane <tgl@sss.pgh.pa.us>
> 
> Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > Platform SPARC Linux 2.0.36, latest CVS.
> 
> SPARC Linux?  Didn't know there was such a thing.  You should look at

It's been around for a while and is very good.

> the machine-dependent assembly coding in s_lock.h and s_lock.c.  Perhaps
> the #ifdefs are messed up such that the wrong bit of code is being
> selected for your platform.  (We do have spinlock code for SPARC, IIRC,
> but I wonder whether it gets selected if the platform name is linux ...)

We appear to have spinlock on this platform and it looks like it works,
see below.

> 
> If the failure just started appearing recently then this probably ain't
> the answer :-(

It's the 1st time I've had a play with the "bench" code so I can't
say if it has ever worked.

The odd thing is that there was nothing else running, no postmaster,
no backends, nothing. It would seem like it's locking itself!!

It's not a major problem to me as everything else works OK, even the
regression tests are 100% excepting error message and precision
differences.

Keith.

> 
> 			regards, tom lane


[postgres@sparclinux buffer]$ make s_lock_test
gcc -I../../../include -I../../../backend   -O2 -Wall -Wmissing-prototypes -I../.. -DS_LOCK_TEST=1 s_lock.c -o s_lock_test
./s_lock_test
S_LOCK_TEST: this will hang for a few minutes and then abort
             with a 'stuck spinlock' message if S_LOCK()
             and TAS() are working.

FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.

FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
make: *** [s_lock_test] IOT trap/Abort (core dumped)
make: *** Deleting file `s_lock_test'
[postgres@sparclinux buffer]$                    


Tue, 25 May 1999 22:24:32 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Re: [HACKERS] Problem in S_LOCK? 

I don't know if I can help, but I'm downloading the
latest snapshot now. I'll see if I can reproduce it.

You might want to try recompiling the spin lock file
without optimization.  

Tom Szybist
szybist@boxhill.com

In message <199905252124.WAA15632@mtcc.demon.co.uk>, Keith Parks writes:
> From: Tom Lane <tgl@sss.pgh.pa.us>
> > 
> > Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > > Platform SPARC Linux 2.0.36, latest CVS.
> > 
> > SPARC Linux?  Didn't know there was such a thing.  You should look at
> 
> It's been around for a while and is very good.
> 
> > the machine-dependent assembly coding in s_lock.h and s_lock.c.  Perhaps
> > the #ifdefs are messed up such that the wrong bit of code is being
> > selected for your platform.  (We do have spinlock code for SPARC, IIRC,
> > but I wonder whether it gets selected if the platform name is linux ...)
> 
> We appear to have spinlock on this platform and it looks like it works,
> see below.
> 
> > 
> > If the failure just started appearing recently then this probably ain't
> > the answer :-(
> 
> It's the 1st time I've had a play with the "bench" code so I can't
> say if it has ever worked.
> 
> The odd thing is that there was nothing else running, no postmaster,
> no backends, nothing. It would seem like it's locking itself!!
> 
> It's not a major problem to me as everything else works OK, even the
> regression tests are 100% excepting error message and precision
> differences.
> 
> Keith.
> 
> > 
> > 			regards, tom lane
> 
> 
> [postgres@sparclinux buffer]$ make s_lock_test
> gcc -I../../../include -I../../../backend   -O2 -Wall -Wmissing-prototypes -I../.. -DS_LOCK_TEST=1 s_lock.c -o s_lock_
> test
> ./s_lock_test
> S_LOCK_TEST: this will hang for a few minutes and then abort
>              with a 'stuck spinlock' message if S_LOCK()
>              and TAS() are working.
> 
> FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
> 
> FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
> make: *** [s_lock_test] IOT trap/Abort (core dumped)
> make: *** Deleting file `s_lock_test'
> [postgres@sparclinux buffer]$                    
> 
> 

Tue, 25 May 1999 20:37:58 -0400
"Thomas A. Szybist" <szybist@boxhill.com>
Re: [HACKERS] Problem in S_LOCK? 
Thanks Tom,

I'll try that next time I do a build.

I may also try building with some of the lock debug
stuff defined.

Keith.

"Thomas A. Szybist" <szybist@boxhill.com>
> 
> I don't know if I can help, but I'm downloading the
> latest snapshot now. I'll see if I can reproduce it.
> 
> You might want to try recompiling the spin lock file
> without optimization.  
> 
> Tom Szybist
> szybist@boxhill.com
> 
> In message <199905252124.WAA15632@mtcc.demon.co.uk>, Keith Parks writes:
> > From: Tom Lane <tgl@sss.pgh.pa.us>
> > > 
> > > Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > > > Platform SPARC Linux 2.0.36, latest CVS.
> > > 
> > > SPARC Linux?  Didn't know there was such a thing.  You should look at
> > 
> > It's been around for a while and is very good.
> > 
> > > the machine-dependent assembly coding in s_lock.h and s_lock.c.  Perhaps
> > > the #ifdefs are messed up such that the wrong bit of code is being
> > > selected for your platform.  (We do have spinlock code for SPARC, IIRC,
> > > but I wonder whether it gets selected if the platform name is linux ...)
> > 
> > We appear to have spinlock on this platform and it looks like it works,
> > see below.
> > 
> > > 
> > > If the failure just started appearing recently then this probably ain't
> > > the answer :-(
> > 
> > It's the 1st time I've had a play with the "bench" code so I can't
> > say if it has ever worked.
> > 
> > The odd thing is that there was nothing else running, no postmaster,
> > no backends, nothing. It would seem like it's locking itself!!
> > 
> > It's not a major problem to me as everything else works OK, even the
> > regression tests are 100% excepting error message and precision
> > differences.
> > 
> > Keith.
> > 
> > > 
> > > 			regards, tom lane
> > 
> > 
> > [postgres@sparclinux buffer]$ make s_lock_test
> > gcc -I../../../include -I../../../backend   -O2 -Wall -Wmissing-prototypes -I../.. -DS_LOCK_TEST=1 s_lock.c -o s_lock_
> > test
> > ./s_lock_test
> > S_LOCK_TEST: this will hang for a few minutes and then abort
> >              with a 'stuck spinlock' message if S_LOCK()
> >              and TAS() are working.
> > 
> > FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
> > 
> > FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
> > make: *** [s_lock_test] IOT trap/Abort (core dumped)
> > make: *** Deleting file `s_lock_test'
> > [postgres@sparclinux buffer]$                    
> > 
> > 


Wed, 26 May 1999 22:00:22 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Re: [HACKERS] Problem in S_LOCK? 

Well, good news and bad news. It seems to work for me. Sorry.
This is a sparc10 running 2.0.30.  Yes, very old.  Soon I can
give Red hat 6.0 a try on an Ultra10.

[szybist@anka post]$ initdb

We are initializing the database system with username szybist (uid=501).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/szybist/post/data/base

Creating template database in /home/szybist/post/data/base/template1

Creating global classes in /home/szybist/post/data/base

Adding template1 database to pg_database...

Vacuuming template1
Creating public pg_user view
Creating view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view pg_indexes
Loading pg_description
[szybist@anka post]$ postgres template1

POSTGRES backend interactive interface 
$Revision: 1.115 $ $Date: 1999/05/22 17:47:49 $

backend> create database bench
blank
         1: datname     (typeid = 19, len = 32, typmod = -1, byval = f)
         2: datdba      (typeid = 23, len = 4, typmod = -1, byval = t)
         3: encoding    (typeid = 23, len = 4, typmod = -1, byval = t)
         4: datpath     (typeid = 25, len = -1, typmod = -1, byval = f)
        ----
backend>


Wed, 26 May 1999 20:49:15 -0400
"Thomas A. Szybist" <szybist@boxhill.com>
Re: [HACKERS] Problem in S_LOCK? 