Re: [HACKERS] PostGreSQL v6.2.1 for Linux Alpha

Bruce Momjian <maillist@candle.pha.pa.us>

From: Bruce Momjian <maillist@candle.pha.pa.us>
To: khollis@Gawain.Houston-InterWeb.COM (Kenji T. Hollis)
Cc: scrappy@hub.org, pgsql-hackers@postgresql.org
Date: 1998-02-12T14:21:06Z
Lists: pgsql-hackers
> 
> Bruce:
> 
> > 	backend/catalog/index.c:298:            func_error("BuildFuncTupleDesc",
> > 	funcname, nargs, argtypes);
> > 
> > The function he is having trouble with is one that gets created by
> > initdb for use in an index.  Must be failing there somehow, but without
> > initdb completing, you can't easily debug to see what is in the pg_proc
> > table.
> 
> That's the line that's the problem.  It seems to find the other routines
> that it needs from the hash table, but this seems to be the culprit in
> both v6.2.1, and the 6.3beta that I'm trying.
> 
> I spent a good day working on finding the problem, and found that this was
> where it lied.  Further study showed it was in hash_getnext, but I didn't
> have time to debug hash_getnext.

Again, I will say that the problems with initdb are usually very
complicated to debug.  It seems like you have gotten pretty far.  For
me, it is just a challenge to get initdb running inside a debugger
because there is so much shell script startup before the postgres
process runs.

Take a look at utils/hash/hashfn.c:tag_hash.  Is there a problem in that
code for your platform.  Is the hash getting set, or is it falling
through the case statements?  This code is clearly broken for
sizeof(int) > 4, but I think your ints are 4, and longs are 8.  I bet
somewhere we are using a long where we should be using an int, and that
is why only your platform is seeing it.  Is this true about long vs.
int.  I can review our use of longs to see if there are problems.




-- 
Bruce Momjian
maillist@candle.pha.pa.us