PostgreSQL 6.5.1 & Alpha (Digital UNIX) - Mailing list pgsql-ports

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.

> ./configure
> creating cache ./config.cache
> checking host system type... alphaev56-dec-osf4.0d
> checking echo setting...
> checking setting template to... osf1
>
> osf1 does not exist
>

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:

> gmake[3]: Entering directory
`/usr/cb-share/Src/postgres/postgresql-6.5.1/src/pl
> /plpgsql/src'
> /usr/bin/yacc -d gram.y
> sed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g' pl_gram.c
> sed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g' pl.tab.h
> rm -f y.tab.c y.tab.h
> flex -i -l scan.l
> sed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g' pl_scan.c
> rm -f lex.yy.c
> /usr/bin/cc -I../../../include -I../../../backend   -DNOFIXADE -std -O2
-Olimit
> 2000 -I../../../interfaces/libpq -I../../../include -I../../../backend -c -o
pl_
> parse.o pl_gram.c
> cc: Error: scan.l, line 85: In this statement, "K_ASSIGN" is not declared.
> { return K_ASSIGN;                      }
> ---------^
> cc: Error: scan.l, line 86: In this statement, "K_ASSIGN" is not declared.
> { return K_ASSIGN;                      }
> ---------^
> cc: Error: scan.l, line 87: In this statement, "K_DOTDOT" is not declared.
> { return K_DOTDOT;                      }
> ---------^
>

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.

> diff -c pl_gram.c.orig pl_gram.c
> *** pl_gram.c.orig      Tue Jul 27 11:41:42 1999
> --- pl_gram.c   Tue Jul 27 11:43:12 1999
> ***************
> *** 41,48 ****
>   #include "string.h"
>   #include "plpgsql.h"
>
> - #include "pl_scan.c"
> -
>   static        PLpgSQL_expr    *read_sqlstmt(int until, char *s, char
*sqlstart);
>   static        PLpgSQL_stmt    *make_select_stmt(void);
>   static        PLpgSQL_expr    *make_tupret_expr(PLpgSQL_row *row);
> --- 41,46 ----
> ***************
> *** 144,149 ****
> --- 142,149 ----
>   PLPGSQL_YYSTYPE plpgsql_yylval, plpgsql_yyval;
>   typedef int plpgsql_yytabelem;
>   # define PLPGSQL_YYERRCODE 256
> +
> + #include "pl_scan.c"
>
>   # line 1081 "gram.y"
>

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:

> postmaster -i
> FATAL: StreamServerPort: bind() failed: Address already in use
>         Is another postmaster already running on that port?
>         If not, wait a few seconds and retry.
> /usr/compbio/pgsql/bin/postmaster: cannot create INET stream port
>

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

> QUERY: update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
> pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally
>         before or while processing the request.
> We have lost the connection to the backend, so further processing is
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
---
>      |Sat May 10 23:59:12 1947 PDT

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

--
Mark Dalphin                          email: mdalphin@amgen.com
Mail Stop: 29-2-A                     phone: +1-805-447-4951 (work)
One Amgen Center Drive                       +1-805-375-0680 (home)
Thousand Oaks, CA 91320                 fax: +1-805-499-9955 (work)