PostgreSQL 6.5.1 & Alpha (Digital UNIX)

Hi,

I have been having some trouble with Postgresql 6.5.1 on a DEC Alpha running
Digital UNIX (OSF1). Some of the problems I can find a work around for while
others have me stopped while I attempt to find a work-around.

My system:
uname -a = OSF1 pongo V4.0 878 alpha
Installed flex v 2.5.4
Installed gmake = GNU Make version 3.77

----------------------------------------------------------------
Problem 1: the sytem is not automatically recognised.
Solution 1: specify "--with-template=alpha_cc"

Overall configuration:
./configure --with-CC=/usr/bin/cc --without-CXX --with-template=alpha_cc
--with-perl

Note: I altered the file template/alpha_cc to use '-O2' instead of '-O4' based
upon the following from 'man cc':

If you are using the -O (or -O2) optimization level when compiling code
that will never end up in a shared library, you should consider chang-
ing to the -O3 level because it provides additional compiler optimiza-
tions. (The -O3 level may inhibit the ability to preempt symbols, so
it should not be used for shared libraries.)

---------------------------------------------
Problem 2: "gmake all" fails while compiling plpgsql:
A great many of the symbols defined, like K_ASSIGN, T_NUMBER, etc fail to be
#defined before they are used. Reading over the code, it seems that "pl_gram.c"
#includes "pl_scan.c" and then #defines the constants, above. I don't know why
this shows up on the DEC and not on my SGI; I assume it is something about flex
and/or yacc. I edited the file pl_gram.c to move the #include to after the
#defines. A diff follows showing the change, but I don't believe it can be a
patch as these files are generated during compilation. Suggestions for how to
fix this are welcome.
In any case, that gets me thru the compilation with only a few Warnings (I'll
come back to some of those).

-----------------------------------------------------
Problem 3: I can't start the postmaster with the '-i' option. I always get the
following error:
A trial using "setenv PGPORT 5532" works, so something on the DEC is using
Postgresql's port. How rude! I am trying to find out what now. How do I go
about tracking down the port user? I don't know if this is Digital UNIX or
some specific software we are running on this system.

Solution 3: use another port.

-----------------------------------------
Problem 4: Regression tests all work well EXCEPT rules.
The following line is from the end of ...../src/test/regress/results/rules.out
impossible. Terminating.
>

I believe I have seen a message like this in the mail lists already, but I don't

recall a solution. Wasn't this something that "Uncle George" reported for the
Linux Alpha as well?

Solution 4: none.

-------------------------------------------
Regression tests list several items as "fail", but are okay:

int2 .. failed
Different wording in output error message
int4 .. failed
Different wording in output error message
float8 .. failed
Different wording in outout error message
geometry .. failed
Rounding errors
abstime .. failed
tinterval .. failed
horology .. failed
Problems with times back in 1947 due to Operating System, not Postgresql.
====== abstime ======
25c25
< |Sat May 10 23:59:12 1947 PST
---
rules .. failed
No idea; this is a genuine failure. See Problem #4 above.

====================================================================================

I usually take Warnings from compilers seriously. There were only a few in the
"gmake all" so I'll pass on the few that may be significant, in case the
developers think these are serious. I haven't looked into these any further.

The first warnings have to do with opening sockets and, initially, I thought
might be to blame for problem #3, above.

cc: Warning: pqcomm.c, line 351: In this statement, the referenced type of the
pointer value "&addrlen" is "unsigned long", which is not compatible with "int".

if ((port->sock = accept(server_fd,
cc: Warning: pqcomm.c, line 361: In this statement, the referenced type of the
pointer value "&addrlen" is "unsigned long", which is not compatible with "int".

if (getsockname(port->sock, (struct sockaddr *) & port->laddr,
cc: Warning: fe-connect.c, line 638: In this statement, the referenced type of
the pointer value "&laddrlen" is "unsigned long", which is not compatible with
"int".
if (getsockname(conn->sock, &conn->laddr.sa, &laddrlen) < 0)


There are many of the following (or similar) which I don't think are serious.

cc: Warning: bufmgr.c, line 490: In this statement, the referenced type of the
pointer value "((volatile slock_t...)&(buf->io_in_progress_lock))" is volatile,
but the referenced type of the target of this assignment is not.
S_LOCK(&(buf->io_in_progress_lock));

The following may be a problem in the oracle-compatibility functions:

cc: Warning: oracle_compat.c, line 190: In this statement, the expression
"ptr2=ptr2==(((struct varlena ...)(string2))->vl_dat)+(((struct varlena
...)(string2))->vl_len)-sizeof(int32)-1?(((struct varlena
...)(string2))->vl_dat):++ptr2" modifies the variable "ptr2"
more than once without an intervening sequence point. This behavior is
undefined.
ptr2 = ptr2 == VARDATA(string2) + VARSIZE(string2) - VARHDRSZ -
1 ? VARDATA(string2) :++ptr2;
cc: Warning: oracle_compat.c, line 250: In this statement, the expression
"ptr2=ptr2==(((struct varlena ...)(string2))->vl_dat)+(((struct varlena
...)(string2))->vl_len)-sizeof(int32)-1?(((struct varlena
...)(string2))->vl_dat):++ptr2" modifies the variable "ptr2"
more than once without an intervening sequence point. This behavior is
undefined.
ptr2 = ptr2 == VARDATA(string2) + VARSIZE(string2) - VARHDRSZ -
1 ? VARDATA(string2) :++ptr2;

======================================================

Hope some of this helps the developers, and I hope someone has some suggestions
for chasing done the problem with the 'rules'.

Thanks,
Mark