Thread: Report on NetBSD/mac port of Postgres 6.4.2

Well I got the patch file from Tatsuo Ishii (thanks!!!) which includes the
NetBSD/m68k fixes by NAKAJIMA Mutsuki (double thanks!!!).  I applied it to
the postgres 6.4.2 distribution and it mostly worked.

Caviats:

1) It won't compile with kerberos 4 enabled.  Yes, I loaded the secr.tar.gz
distribution, but there are some serious problems with kerberos on my
machine so this may not be Postgres' fault.  (Yes I adjusted the various
names/paths for NetBSD differences.)

2) The following four regression tests fail:
geometry
datetime
horology
inet

Geometry appears superficially to be the usual roundoff problems.  Inet
looks superficially to me like the MacBSD output may be more correct, but I
don't know what's going on well enough to be sure.  Horology is likely to
fail due to some obscure dates which are tested, but I haven't verified if
that's the only problem in this case.

The datetime failure looks to be serious.  'now'::datetime -
'current'::datetime yields more than 200 days!

If anyone (Tom?) wants an account on a Quadra 840av to investigate the
problem further let me know.  The apparent speed of the beast is about half
of my SPARCstation 5 or around 1/4 of a beefed up Ultra 5 so it's fast
enough not to kill you.  Anyone who can get real work done on an SE/30
(NAKAJIMA Mutsuki) has my respect for their patience.
__________________________________________________________
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

> The datetime failure looks to be serious.  'now'::datetime -
> 'current'::datetime yields more than 200 days!

I've seen similar symptoms with machines that have timezone troubles, or
more accurately timezone support which is not mapped correctly into the
Postgres timezone handling code. Could be that ./configure is confused.

> If anyone (Tom?) wants an account on a Quadra 840av to investigate the
> problem further let me know.

Hi Henry. It is possible, and if I had my druthers I'd have an account
with group privileges to work directly in a patched Postgres tree
(perhaps the one you have already built). Any running servers would need
to be shut down to allow me to fire up debugging versions. Also, again
if possible, I would have access after-hours via one of my machines in
your domain. And if I can't see the problem right away (if I glance at
it a lunch time) then I wouldn't be able to look 'til next week.
                           - Tom

-- 
Thomas Lockhart
Caltech/JPL
Interferometry Systems and Technology

> Well I got the patch file from Tatsuo Ishii (thanks!!!) which includes the
> NetBSD/m68k fixes by NAKAJIMA Mutsuki (double thanks!!!).  I applied it to
> the postgres 6.4.2 distribution and it mostly worked.
> 
> Caviats:
> 
> 1) It won't compile with kerberos 4 enabled.  Yes, I loaded the secr.tar.gz
> distribution, but there are some serious problems with kerberos on my
> machine so this may not be Postgres' fault.  (Yes I adjusted the various
> names/paths for NetBSD differences.)

Seems kerberos support in PostgreSQL has been broken for quite
sometime.

> 2) The following four regression tests fail:
> geometry
> datetime
> horology
> inet
> 
> Geometry appears superficially to be the usual roundoff problems.  Inet
> looks superficially to me like the MacBSD output may be more correct, but I
> don't know what's going on well enough to be sure.

There is a known bug with inet data type in 6.4.2, that happens on
m68k, PowerPC and Sparc as far as I know. I believe this has been
fixed in current. If you need patches for 6.4.2, please let me know.

> Horology is likely to
> fail due to some obscure dates which are tested, but I haven't verified if
> that's the only problem in this case.
> 
> The datetime failure looks to be serious.  'now'::datetime -
> 'current'::datetime yields more than 200 days!
> 
> If anyone (Tom?) wants an account on a Quadra 840av to investigate the
> problem further let me know.  The apparent speed of the beast is about half
> of my SPARCstation 5 or around 1/4 of a beefed up Ultra 5 so it's fast
> enough not to kill you.  Anyone who can get real work done on an SE/30
> (NAKAJIMA Mutsuki) has my respect for their patience.

I heard from Mutski that he spent more than 6 hours to compile
PostgreSQL on his SE/30:-)
---
Tatsuo Ishii