Bruce Momjian wrote:
> >
> > 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.
I recall seeing the "Datum" type in the code as an int/pointer coersed type. That
is, there are lots of places where it is forced from an int to a pointer and back
again. Might look at that, and make sure it is a long/pointer rather than an
int/pointer. Of course, that may have already been fixed up...
- Tom
