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

>     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".  ;)

>     ...first question is, how many ppl out there are running under a
> Linux/Alpha platform, or at least are trying?  I don't have one myself, so
> can only be of limited help...

I'm not really sure - I've had this Alpha here for about 6 months and I
have resulted to using msql since that's about the only thing that will
work efficiently.

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

>     We can't debug this for you (well, I imagine Thomas would love it
> if you sent him a Linux/Alpha machine, then he could help you *grin*), but
> if you are willing, we can try and steer you towards a solution...

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?

-- Ken
------
   =========================================================================
      Houston InterWeb Design, Inc.     ||      Office: +1 (713) 627-9494
      Lead Programmer/Designer          ||         Fax: +1 (713) 627-2744
      C++, Windows, and Web Programming ||       Pager: +1 (713) 727-2529
   =========================================================================
               Home page URL: http://www.houston-interweb.com/