FAQ
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)

Search Discussions

  • Adriaan Joubert at Jul 28, 1999 at 6:04 am

    Mark Dalphin wrote:
    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
    This is strange. I've got exactly the same environment, (bison 1.25),
    for the rest identical, and it builds out of the box for me (I compiled
    without C++, though). There must be something else in your environment.
    Haven't done the regression tests yet, but half of them always seem to
    fail on Alpha ;-) Tends to work ok anyway.

    Adriaan
  • Mark Dalphin at Jul 29, 1999 at 12:15 am

    Adriaan Joubert wrote:

    Mark Dalphin wrote:
    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
    This is strange. I've got exactly the same environment, (bison 1.25),
    for the rest identical, and it builds out of the box for me (I compiled
    without C++, though). There must be something else in your environment.
    Haven't done the regression tests yet, but half of them always seem to
    fail on Alpha ;-) Tends to work ok anyway.

    Adriaan
    Hmmm - the same environment except 'bison' and it compiles out of the box. I gotta
    see this...

    Added bison = GNU Bison version 1.28

    Same configure as before:
    ./configure
    --with-template=alpha_cc
    --with-CC=/usr/bin/cc
    --with-perl
    --without-CXX
    --prefix=/my-directory
    --with-libs=/path-to-my/libreadline.a
    --with-includes=/path-to-my/include/readline/

    Sure enough, it did compile right out of the box. I don't know if this is true on
    all systems, but I see that this happens on the HP systems as well (recently in
    pgsql-ports mail list). Perhaps a brief note in the INSTALL document near the
    comments about flex would be in order?

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

    I still fail in the regression tests on the 'rules'. The following is from
    ..../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.
    The previous test rules appear to be working correctly. Any ideas on what is
    happening here? As I am not using rules currently, I do not believe I'll take the
    time to track this down further at this time.

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

    My comment on the port being occupied has been tracked down to a commercial Batch
    Queue we use for distributing our load over 2 dozen Alphas. It is called "LSF
    Batch" by Platform Computing (www.platform.com). They use TCP/IP port 5432 for
    coordinating the batch jobs. I haven't looked into whether they can be configured
    onto another port as I know that Postgresql can.

    Cheers,
    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)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedJul 28, '99 at 12:00a
activeJul 29, '99 at 12:15a
posts3
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

Mark Dalphin: 2 posts Adriaan Joubert: 1 post

People

Translate

site design / logo © 2022 Grokbase