>
> 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
