Status of Alpha/Unix - Mailing list pgsql-hackers

From Peter Stockwell
Subject Status of Alpha/Unix
Date
Msg-id 199802190252.PAA30715@sanger.otago.ac.nz
Whole thread Raw
List pgsql-hackers
Bruce Momjian wrote:

>Date: Wed, 18 Feb 1998 10:57:35 -0500 (EST)
>From: Bruce Momjian <maillist@candle.pha.pa.us>
>Subject: Re: [HACKERS] Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd)
>
>OK, where are we with Alpha now?  Dec Unix and Alpha Linux users, what
>is your status.  Is anyone geting through initdb, and if so, how?
>
>
>> Hi, all.
>>
>> I'm forwarding this message I posted to psql-ports, because I've seen no
>> answer on it, and the D-day approaches...
>>
>> ---------- Forwarded message ----------
>> Date: Mon, 16 Feb 1998 12:48:49 +0100 (MET)
>> From: "Pedro J. Lobo" <pjlobo@euitt.upm.es>
>> To: PostgreSQL ports mailing list <pgsql-ports@postgresql.org>
>> Subject: Feb. 15 snapshot doesn't compile on alpha / Digital Unix
>>
>> Hi, folks.
>>
>> The good news: I compiled 6.3 beta on Digital Unix 3.2c using the DEC C
>> compiler.
>>
>> The bad news: It doesn't work :-(
>>
[...]
>
>>
>
>
>- --
>Bruce Momjian
>maillist@candle.pha.pa.us
>

Status with V6.3b on Alpha/Unix is that present snapshot 18,19-Feb
won't install with some error relating to ecpglib.h.  I've posted this
to ports-pgsql, but the problem has persisted.

I'm still struggling to find out what is wrong with initdb on the
17-Feb snapshot and I have found that the mkoidname error originates
from the line

declare index pg_attribute_relid_attnam_index on pg_attribute using btree(mkoidname(attrelid, attname) oidname_ops)

and that postgres is failing when BuildFuncTupleDesc fails to resolve
the tuple with call to SearchSysCacheTuple.

The lookup methods used in the resolution is not transparently obvious
to me and I have not yet managed to spot any clear source of the
problem.

I am about to try checking the operation of the bootstrap logic at the
time of insertion - at the template line

insert OID = 949 ( mkoidname 1200 11 f t f 2 f 911 "26 19" 100 0 0 100 foo bar)

to see if some related value is being corrupted at this stage.  Since
I don't have a lot of experience in the way postgres handles such
things, any suggestions will be welcome.  Since I have not really used
gdb previously this is, in itself, a learning experience.

Regards

Peter A. Stockwell

peter@sanger.otago.ac.nz

pgsql-hackers by date:

Previous
From: "Vadim B. Mikheev"
Date:
Subject: Re: [HACKERS] Unexpected subselect result.
Next
From: "Vadim B. Mikheev"
Date:
Subject: Re: [HACKERS] Unexpected subselect result.