Status of Alpha/Unix
От | Peter Stockwell |
---|---|
Тема | Status of Alpha/Unix |
Дата | |
Msg-id | 199802190252.PAA30715@sanger.otago.ac.nz обсуждение исходный текст |
Список | 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 по дате отправления: