Re: [HACKERS] Also on SVR4 (Compiling 6.4 on NetBSD-current/pc532) - Mailing list pgsql-hackers

Thomas G. Lockhart writes:
 > > I have a current version of PostgreSQL running on my pc532 now.
 > > (It's a NS32K based machine.  Somewhat of an antique really...)
 > > It did not, however, get the datetime test correct.
 > > ... I suspect (a NetBSD/pc532 problem) due to a lack of people
 > > screaming.
 >
 > Screaming means you get to help do development :)
 >
 > > I did build 6.3.2 with -DDATEDEBUG, but I'm not coherent enough
 > > (yet?) to properly deduce anything yet.  It appeared to all be
 > > correct until it printed the results, implying that libc or a
 > > syscall was returning some funny constant perhaps?
 >
 > Ah. It's slowly coming back to me, so here are some suggestions:
 >
 > "epoch" and "current" are stored internally in the database so that the
 > support code can pull one back out and say "oh! that's supposed to be
 > 'epoch'", for example. So, I used _very_ small floating point numbers to
 > represent those special constants (numbers much smaller than one could
 > get by doing the usual arithmetic, at least under normal circumstances).
 >
 > I'll bet that your machine is somehow pushing those numbers to be
 > exactly zero, which corresponds to Y2K (with the timezone offset, that
 > is what you are seeing). So, try looking at the numbers, and try seeing
 > what they are being set to. In src/include/utils/dt.h, you will see that
 > current and epoch are being set to DBL_MIN and -DBL_MIN, respectively.
 > Make sure that these are not identical to zero (they are something like
 > 1e-308 on my machine). You can change dt.h to make these some other
 > usually unique number, say +/-1e-20 for now.
 >
 > And track down why DBL_MIN on your machine isn't the smallest allowed
 > double-precision number...
 >
 >                     - Tom

Well, finally somebody, who sees the same problems as me. I had the
same problems with 6.3, which I didn't pursue due to lack off time.

However, now I retried with the 6.4 snapshot from Sep. 11. I compiled
under Siemens SINIX (Mips based SVR4) and the system cc.

If I issue the following sql statement, the backend dies with a core.

  regression=> select ('now'::datetime - 'current'::datetime) as "Zero";

I guess the following result is ok.

  regression=> select ('current'::datetime) as "Zero";
  Zero
  -------
  current
  (1 row)

I guess, somehow the applying math operators to datetime causes the
core dumps.

Here is the GDB stack trace from the core. (Only dt.c

$ gdb ../../../bin/postgres core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15.1 (mips-sni-sysv4), Copyright 1995 Free Software Foundation, Inc...
Core was generated by `/local/pgsql-6.4/bin/postmaster -i -p 2222 '.
Program terminated with signal 10, Bus error.
Reading symbols from /lib/libnsl.so...done.
Reading symbols from /lib/libsocket.so...done.
Reading symbols from /lib/libdl.so...done.
Reading symbols from /lib/libmutex.so...done.
Reading symbols from /usr/lib/libc.so.1...done.
(gdb) where
#0  0x51595c in tm2datetime (tm=0x7fffb334, fsec=1.0609881999384027e-314,
    tzp=0x5db6d4, result=0x542658) at dt.c:2517
#1  0x50e8cc in SetDateTime (dt=2.2250738585072022e-308) at dt.c:346
                                ^^^^^^^^^^^^^^^^^^^^^^^
                this is DBL_MIN

#2  0x510884 in datetime_mi (datetime1=0x60d370, datetime2=0x60d3d0)
    at dt.c:783
#3  0x5420b0 in fmgr_c ()
#4  0x46cf98 in ExecMakeFunctionResult ()
#5  0x46d034 in ExecEvalOper ()
#6  0x46d418 in ExecEvalExpr ()
#7  0x46d838 in ExecTargetList ()
#8  0x46dbf8 in ExecProject ()
#9  0x476e14 in ExecResult ()
#10 0x46b32c in ExecProcNode ()
#11 0x46a3e0 in ExecutePlan ()
#12 0x469ab0 in ExecutorRun ()
#13 0x4fc9dc in ProcessQueryDesc ()
#14 0x4fcabc in ProcessQuery ()
#15 0x4faa10 in pg_exec_query_dest ()
#16 0x4fa7dc in pg_exec_query ()
#17 0x4fc0a8 in PostgresMain ()
#18 0x4d6a64 in DoBackend ()
#19 0x4d6260 in BackendStartup ()
#20 0x4d5050 in ServerLoop ()
#21 0x4d4840 in PostmasterMain ()
#22 0x4875c0 in main ()
#23 0x418004 in __start ()
(gdb)

Does this give you some additional hints?

Oh, one more thing. With 6.3, when psql lost connection with the
backend, I got an error message saying so. With 6.4 it psql seems to
be simply hanging.
--
MfG/Regards
--
     /====                         Siemens Nixdorf Informationssysteme AG
    /    Ridderbusch        / ,   Abt.: OEC XS QM4
   /                       /./   Heinz Nixdorf Ring
  /=== /,== ,===/  /,==,  //    33106 Paderborn, Germany
 /    //   /   /  //   / / \   Tel.: (49) 5251-8-15211
/    /     `==/\ /    / /   \ Email: ridderbusch.pad@sni.de

Since I have taken all the Gates out of my computer, it finally works!!