Re: [HACKERS] PostGreSQL v6.2.1 for Linux Alpha - Mailing list pgsql-hackers

On Wed, 11 Feb 1998, Kenji T. Hollis wrote:

> >     No, this isn't...generally we tend to try and point you in the
> > right direction towards determining the problem...
>
> Instead of bitching out at the person who found the problem.  I see.
> Maybe I should have said "pretty please".  ;)

    Nope, that wouldn't have helped either...its difficult for us to
attempt to debug a problem with a platform that we don't have access to,
so we tend to rely on the person reporting the problem to provide us as
much detail as possible concerning the problem.  At times, you have to
nudge the developers a little more then others, but its a volunteer
development environment, and everyone has their own priorities...:(

> >     ...next, do you actually get a core file that you can analyze
> > using gdb?  If so, what do the results show?
>
> I get a core file, but it doesn't tell me squat,

    It can generally tell you alot...do you have gdb on your system?
have you compiled with -g (debugging symbols) compiled in?  Using gdb and
the core file, you should be able to get pretty close to the exact line
(and values) where the error is occuring...combine that with 'script', and
you can pretty much give us a screen capture of what you are doing...

> I've actually zeroed in on the problem.  It lies somewhere in the
> SearchSysCache routine.  I'm attempting to debug it now...  So far, what I
> get is: (Note "[KTH]" is a debug message added by yours truly)
>
> --- SearchSysCache starts here ---
> SearchSysCache: [KTH] Hash: 433
> SearchSysCache: [KTH] Tuple not found in cache, attempting to find.
> SearchSysCache: [KTH] RelationGetRelationName (pg_proc)
> SearchSysCache: performing scan (override==0)
> SearchSysCache: [KTH] IsBootstrapProcessingMode() is true
> SearchSysCache: [KTH] relation check skipped.
> SearchSysCache: [KTH] heap_beginscan is okay.
> heap_getnext([pg_proc,nkeys=3],backw=0,0x1ffff040) called
> heap_getnext returning EOS
> SearchSysCache: [KTH] heap_getnext returns null
> SearchSysCache: [KTH] tuple not found.
> SearchSysCache: [KTH] Heap scan ends.
> SearchSysCache: Heap tuple (ntp) is invalid.
> ERROR:  BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
> ERROR:  BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
> --- End of debug ---
>
> Looks like it lies somewhere in heap_getnext.  Heap_getnext is a HUMONGOUS
> command, and I'm not about to spend another 2 hours debugging that.  ;)
>
> Anyone have any suggestions of a patch for this?

    Bruce...I just checked backend/catalog/index.c, where
BuildFuncTupleDesc() exists, and there is no error message that matches
his above ERROR...

    Ken...look at the top of backend/catalog/index.c and tell me what
version it stays it is?  On the $Header: line?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org