Thread

1. Linux/Alpha Regression tests....

   Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1998-10-31T01:37:00Z

   	Ok, here is a run down on the regression tests for
   pgsql snapshot (09271998) on Linux/Alpha:
   
   int2 .. failed - Difference in error messages. (ok)
   int4 .. failed - Wrapped number when should have errored. (ok)
   float4 .. failed - Overflow and underflow numbers rounded to inf and
                      9.99999E-40 when error message should have resulted.
   		   (ok)
   float8 .. failed - Same as above. (ok)
   numerology .. failed - First same as int4, then a backend failure.
                          (Problem?)
   geometry .. failed - Off by one in nth decimal place. (ok)
   datetime .. failed - Problems with adding time to 'today'. (Problem!)
   reltime .. failed - More time calculation failures. (Problem!)
   abstime .. failed - All dates a long way off, by a few hundred years.
                       (PROBLEM!)
   tinterval .. failed - Same as above. (PROBLEM!)
   horology .. failed - Same as above. (PROBLEM!)
   select_having .. failed - Backend failure, probably memory violation.
                             (Problem)
   union .. failed - Same as int4. (ok)
   random .. failed - Failure on a type and oid, wierd. (Problem?)
   misc .. failed - More wierd errors. :( (Problem?)
   
   	It appears most of the problems are concentrated in the datetime
   code, and the rest of the problems are cascade failures from trying to use
   the faulty datetime functions for more extensive tests. There are a few
   other problems (i.e. select_having), but I feel that the datetime stuff
   needs to be sorted out first.
   	I have tried to figure out what is up with the datetime code many
   times, but always ended in a dead end. Any test programs I write to see if
   I can isolate the problem work fine. Any attempts at debugging are
   fruitless as gdb is not 100% stable on Linux/Alpha and gets lost sometimes
   (returning random values for memory address! :( ).
   	What I have been able to track down that any call to localtime()
   library call is returning a date at some point in the year 2136! The
   system clock is correct. localtime() does conversion between time formats
   and somewhere it is getting its feet stepped on. Date time data going in
   is fine, but coming out it is scrambled. Test programs that just run data
   through localtime() work just fine. 
   	Also, this only seems to happen when 'today' (if I
   remember correctly) is used for datetime input. Actual dates seem to work
   just fine though.
   	The biggest trouble in finding this bug is how "complex" the
   datetime code is... Actually after hacking at it for a few hours (with no
   success) I have other words to describe it, but I will refrain. :) Might
   some one explain to me what exactly is happening in the datetime code so I
   might have some idea what is going on. I am relatively good at C, but even
   this tests my skills pretty good. 
   	As I find time, I will work further to resolve these problems. If
   any one else has any ideas or advice on how to solve this problem, please
   send them my way!
   
   	PS. If some of this appears vague, it is. I have not had time to
   hack recently on pgsql thanks to too much schoolwork. :( Just with the 6.4
   release going out soon, I though I better see what help I could find...
   
   	PPS. Patch for pgsql snapshots to compile on Linux/Alpha are
   coming shortly.
   
   ----------------------------------------------------------------------------
   |   "For to me to live is Christ, and to die is gain."                     |
   |                                            --- Philippians 1:21 (KJV)    |
   ----------------------------------------------------------------------------
   |  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
   ----------------------------------------------------------------------------
   |               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
   ----------------------------------------------------------------------------
   
   
   

2. Re: [PORTS] Linux/Alpha Regression tests....

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-31T03:32:57Z

   > The biggest trouble in finding this bug is how "complex" the
   > datetime code is... Actually after hacking at it for a few hours (with 
   > no success) I have other words to describe it, but I will refrain.
   
   I'll assume it would be a compliment :) I was happy with how simple I
   was able to make the code. Date/time stuff ain't easy.
   
   I'm guessing that the problem is in one of two areas:
   
   1) the configure/build process is confused as to what kind of time
   support you have on your system. There are two styles of local time
   conversion interfaces on Unix systems: one which uses global variables
   to return info on time zones, and one which returns that info as part of
   the tz structure. The third type, which is pretty much no timezone
   support, is probably not relevant, though if your system is really
   confused you should eliminate that as a possibility. The second type is
   reentrant, the first is not. It doesn't really matter which kind your
   system uses because each backend is essentially single-threaded, but if
   it guesses wrong on what kind of system you have then the results will
   be garbage.
   
   2) the Postgres code stomps on the global variables used for timezone
   info. I think I got that resolved, but I figured I should mention it
   just in case.
   
   It is most likely that (1) is the problem. Try compiling with
   "-DDATEDEBUG" specified, and see if that helps you track through the
   code. Though it seems like you already know where the problem is
   located, so I'd just pound on an example until you get it figured out.
   
   Good luck.
   
                          - Tom