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

On Wed, 18 Mar 1998, Thomas G. Lockhart wrote:

>> hash_index ..  ok
>> select_views ..  ok
>> alter_table ..  ok
>> portals_p2 ..  ok
>> ==========================================
>>
>> Some of them fail (most notably int2, int4 and float8), but anyway it's
>> better than before :-)
>
>Oooh. I think you might have a running system now! Those int2, int4,

Yes, it seems so.

>float8 "failures" are probably just error message differences and are
>expected.

Yes. For int2: Expected:
! ERROR:  pg_atoi: error reading "100000": Math result not representable

Got:
! ERROR:  pg_atoi: error reading "100000": Result too large

For int4: Expected:
! ERROR:  pg_atoi: error reading "1000000000000": Math result not
representable

Got:
! ERROR:  pg_atoi: error reading "1000000000000": Result too large

The same goes for oidint2 and oidint4.

For float8: Expected:
! ERROR:  Bad float8 input format -- overflow

Got:
! ERROR:  floating point exception! The last floating point operation
either exceeded legal ranges or was a divide by zero

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?

>The date and time stuff may or may not be a problem, and the
>geometry stuff is probably OK (rounding trouble in the math libraries).

You are right on the geometry stuff. I am not sure about the date stuff.
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.

>Make sure your date/time stuff looks OK, at least for simple tests; it
>may be, for example, that your timezone database is just different for
>dates before 1960...

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

Also, the test fails form the random stuff:
*** expected/random.out ma 29 abr 07:23:40 1997
--- results/random.out  ma 17 mar 03:51:57 1998
***************
*** 7,18 ****
  QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
  count
  -----
!    92
  (1 row)

  QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
  count
  -----
!    98
  (1 row)

--- 7,18 ----
  QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
  count
  -----
!    95
  (1 row)

  QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
  count
  -----
!    88
  (1 row)


----------------------


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

-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 1 336 78 19
Centro de Cálculo                       Fax:    +34 1 331 92 29
EUIT Telecomunicación - UPM             e-mail: pjlobo@euitt.upm.es