Re: Unix Domain Sockets error (was Re: [HACKERS] Alpha initdb fixed!)

> This one was harmless, but there is another one: Expected:
>   QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
> ! bad|            ?column?
> ! ---+--------------------
> !    |                   1
> !    |7.39912306090513e-16
> !    |                   0
> !    |                   0
> !    |                   1
> ! (5 rows)
> !
>
> Got:
>   QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
> ! ERROR:  exp() result is out of range
>
> Can someone comment on this?

I think you are getting a better result than the regression test machine
gets. That's good.

> Some are differences of one second between the expected and the actual
> results, some others are dates that appear displaced by 19 years (for
> example, expecter year 1997 becomes 2016, expected 1957 becomes
> 1976...). The diff output is very long on this.
> The date/time stuff has never worked completely right. And, if the
> problem lies in postgres, that's ok. Sooner or later it will be fixed.
> But if, as it seems, the problem lies in the timezone databases, we
> might be in big trouble. Perhaps we could make a test, so we can say
> for sure "your timezone database is incorrect, go and ask your verdor
> for a patch".

No, you still have date/time trouble, and it looks as though the
timezone stuff is not being set properly. By definition, it is a problem
with your machine, since the code works on several other platforms, and
no, it isn't likely to get fixed eventually unless you pursue it, since
it does work on the ~20 other OS/processor combinations listed as
supported platforms.

OK, what I meant by "timezone database" trouble would have been sort of
obvious in that only dates from times before computers existed would
have shown problems, and then usually 1 hour differences due to daylight
savings time settings. That is not what you are seeing.

The 19 year differences usually seem to come from mis-handling the
HAVE_INT_TIMEZONE compile-time option. How is yours set? Try changing it
in config.h and see if it helps.

> Yes, the results are different, but... aren't they random? O:-)

Right. OK for random to be different.

                        - Tom