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

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(dot)pad(at)sni(dot)de

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