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)