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

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> wrote:

> > 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 :)

Doh! opened my mouth one too many times... 8-)

> > 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...

I think I saw PostgreSQL say "0" in some of those debug messages,
I'll recompile tonight using some number that's a bit bigger and
see what happens.  I'm not totally sure that's the problem though.
(It probably used to be, since the NS32K floating point hardware
has no concept of a denormalized number, except that it can trap
to some software routine to take care of doing the real work for
it.  Ian Dall wrote all that last year, bless his heart.)

However, I just ran this test code that turns up some problems with
the libc routines, but conclusively shows that the number is not read
correctly with scanf, but is not zero either...

#include <stdio.h>
#define DBL_MIN         2.2250738585072014E-308
void main () {
  double x;
  scanf ("%g", &x);
  printf ("%g   %g %d %d\n", DBL_MIN, x, DBL_MIN == x, x == 0.0);
}

It spits out the following (notice that I cut and pasted the DBL_MIN value):
a.out
2.2250738585072014E-308
2.22507e-308   6.79039e-313 0 0

I'll chase this further with Phil Nelson the NetBSD/pc532 port-master.
Thanks everyone for all your help,

Jon Buller