Re: [PORTS] RedHat6.0 & Alpha

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Ryan Kirkpatrick <rkirkpat(at)nag(dot)cs(dot)colorado(dot)edu>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, Uncle George <gatgul(at)voicenet(dot)com>, pgsql-ports(at)postgreSQL(dot)org
Subject: Re: [PORTS] RedHat6.0 & Alpha
Date: 1999-07-28 14:34:56
Message-ID: 379F1510.35C4A3A6@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-ports

> > Great. But I'm looking for feedback from Ryan if he has a chance to
> > test it.
> Sorry, I have been a bit busy over the weekend. I did get to test
> it on Friday though. The patch applied flawlessly to that day's snapshot.
> Though I quickly hit a minor, but annoying snag. The configure script
> detects my XLT 366 Alpha's CPU as 'alphaev5', which means that none of the
> alpha conditional clauses in the makefiles get evaluated correctly, and
> one ends up with a binary that gets stuck spinlocks (when using -O2 for
> CFLAGS).
> I couldn't find anyway to tell make to look for alpha only at the
> start of the CPU string (i.e. '$CPU =~ /^alpha.*/' in perl syntax), but
> there might be one I missed. I simply ran configure, then edited
> makefile.global, and changed 'alphaev5' to 'alpha' and complied as usual.

Hmm. That can probably be worked around with an entry in
Makefile.custom, though I haven't looked at the specific usage.

> This time it worked great! No stuck spinlocks (and -O2 was used!),
> and all the regression tests, saved for rules as Uncle G. has already
> mentioned.

Fantastic.

> So, other than the CPU type detection problem, everything looks
> very good. I have given postgres a decent work out, loading large data
> sets (8 tables, 88k records), and then accessing via a web interface I am
> writing for work, without any problems at all.
> If no one minds, I will forward Uncle G.'s patches onto some
> Debian-Alpha hackers that contacted me a while back about the status of
> pgsql on alphas, and see what reaction they have to them.

Forwarding the patches is good. Is there anything in them which could
possibly damage a non-alpha machine? If not, and if they are on the
right track (they must be, since things actually work finally :) then
they should eventually end up in our main tree.

In glancing through the patches, I notice that one change is to pass
"Datum" to all ADT functions which take a char, int2, or int4. That
certainly makes the code uglier, but I can see that fudging the calls
as we did earlier might have led to trouble.

In the meantime, they could end up in Linux RPMs as patches to the
pristine distribution, and could be in new RPMs released through
RedHat. They will be very excited (or at least as excited as they
get... ;)

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 1999-07-28 14:51:17 Re: Selectivity of "=" (Re: [HACKERS] Index not used on simple se lect)
Previous Message Tom Lane 1999-07-28 14:19:40 Re: [HACKERS] SELECT FOR UPDATE in (PL/pgSQL) function

Browse pgsql-ports by date

  From Date Subject
Next Message Eichert, Diana 1999-07-28 15:10:33 RE: [PORTS] error compiling odbc support for 6.5.1 under OpenBSD
Previous Message Adriaan Joubert 1999-07-28 06:04:36 Re: [PORTS] PostgreSQL 6.5.1 & Alpha (Digital UNIX)