Thread

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

   Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-11T13:34:57Z

   Brian:
   
   > > I wrote a message about 4 months ago asking about an Alpha Linux version
   > > of PostGreSQL.  Last I heard, they were working on it and it would be
   > > released in early January with a 64-bit clean version of the server.
   > > 
   > > This is my third request.
   > 
   > So, fix it your own self and stop whining.  Can't fix it?  Too bad, I
   > guess you'll just have to wait until they get around to it.
   
   Is this how you guys normally handle inquiries?  Idiot replies like this?
   Oh by the way, I tried fixing it.  Next question?
   
   -- 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/
   
   
   

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

   Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-11T15:57:30Z

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

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

   Marc G. Fournier <scrappy@hub.org> — 1998-02-11T20:30:04Z

   On Wed, 11 Feb 1998, Kenji T. Hollis wrote:
   
   > Brian:
   > 
   > > > I wrote a message about 4 months ago asking about an Alpha Linux version
   > > > of PostGreSQL.  Last I heard, they were working on it and it would be
   > > > released in early January with a 64-bit clean version of the server.
   > > > 
   > > > This is my third request.
   > > 
   > > So, fix it your own self and stop whining.  Can't fix it?  Too bad, I
   > > guess you'll just have to wait until they get around to it.
   > 
   > Is this how you guys normally handle inquiries?  Idiot replies like this?
   > Oh by the way, I tried fixing it.  Next question?
   
   	No, this isn't...generally we tend to try and point you in the
   right direction towards determining the problem...
   
   	...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...
   
   	...next, do you actually get a core file that you can analyze
   using gdb?  If so, what do the results show?
   
   	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...
   
   
   
   
   

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

   Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-12T01:05:07Z

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

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

   Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-12T01:15:42Z

   Bruce:
   
   > The problem here is that it can't find the function to make/use the
   > index.  Try using initdb --debug to get more output, and see what is
   > says about the mkoidname function creation.  Looks like pg_proc is not
   > working, because a scan is returning nothing.  mkoidname is function
   > used to index pg_attribute.  If you do initdb with --noclean, is
   > data/template1/pg_proc indeed zero bytes.  Try adding a define to the
   > postgres.h
   >
   > #define long int
   > 
   > and see if it works.  Maybe the 64-bit longs are causing problems, and
   > we have to fix them or change to ints.
   
   Okay, I can try this.  In the current version of Postgres, when I run
   "initdb --debug", I get the following output:
   
   > CREATED relation pg_description with OID 17847
   > Commit End
   Amopen: relation pg_description. attrsize 63
   create attribute 0 name objoid len 4 num 1 type 26
   create attribute 1 name description len -1 num 2 type 25
   > Amclose: relation (null).
   > initdb: could not create template database
   initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1
   
   Installing the "#define long int" gives about 40 pages of errors.
   
   > Make sure you turn on Assert checking in configure so it may give you an
   > earlier error.
   
   I have no idea of how to do set this in configure.  Configure has no
   option to do this.
   
   > These are very hard to debug because there is no running system to run
   > tests on, and it is all very inter-related.
   
   I can give access to my Alpha, but I have to talk to the person I am
   dealing with.  I *will not* give access to this machine with a complete
   stranger via E-Mail.
   
   > My lib/local1_template1.bki.source has the following two lines for this
   > function:
   > 
   > insert OID = 949 ( mkoidname PGUID 11 f t f 2 f 911 "26 19" 100 0 0 100 foo bar)
   > declare index pg_attribute_relid_attnam_index on pg_attribute using btree(mkoidname(attrelid, attname) oidname_ops)
   
   Exact carbon-copy of mine.
   
   > That is all the ideas I have for now.  Would like to get it working.
   
   So would I.  Bruce, If you would like access to the Postgres machine,
   please feel free to give me a call tomorrow. 
   
   -- 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/
   
   
   

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

   Marc G. Fournier <scrappy@hub.org> — 1998-02-12T01:26:19Z

   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 
   
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T01:37:42Z

   > > > 	...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...
   
   I think it is at:
   
   	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.
   
   
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T04:36:24Z

   > --- 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 ---
   
   The problem here is that it can't find the function to make/use the
   index.  Try using initdb --debug to get more output, and see what is
   says about the mkoidname function creation.  Looks like pg_proc is not
   working, because a scan is returning nothing.  mkoidname is function
   used to index pg_attribute.  If you do initdb with --noclean, is
   data/template1/pg_proc indeed zero bytes.  Try adding a define to the
   postgres.h
   
   #define long int
   
   and see if it works.  Maybe the 64-bit longs are causing problems, and
   we have to fix them or change to ints.
   
   Make sure you turn on Assert checking in configure so it may give you an
   earlier error.
   
   These are very hard to debug because there is no running system to run
   tests on, and it is all very inter-related.
   
   My lib/local1_template1.bki.source has the following two lines for this
   function:
   
   insert OID = 949 ( mkoidname PGUID 11 f t f 2 f 911 "26 19" 100 0 0 100 foo bar)
   declare index pg_attribute_relid_attnam_index on pg_attribute using btree(mkoidname(attrelid, attname) oidname_ops)
   
   That is all the ideas I have for now.  Would like to get it working.
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us
   
   

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

   Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-12T10:06:38Z

   Bruce:
   
   > 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 created a small program to return the size of values.  They are:
   
   Size of short: 2
   Size of char:  1
   Size of int:   4
   Size of long:  8
   
   Does this help?
   
   -- 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/
   
   
   

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

    Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-12T10:09:30Z

    Bruce:
    
    > OK, I have a new idea.  See in utils/hash/hashfn.c:tag_hash, there is
    > the line:
    > 
    >             for (; keysize > (sizeof(int) - 1); keysize -= sizeof(int),key++)
    >                 h = h * PRIME1 ^ (*key);
    > 
    > Now, since h is a long, shouldn't the for loop be comparing
    > sizeof(long)?  However, key is an int*.  
    
    How is this a problem?  *key is getting the value of the current pointer
    of key.  This means, if key contains a string: "Ooga" and key++, then the
    value of *key would be "o" in decimal.  This is a standard hashing
    routine, and the problem does not lie here as far as I can see.
    
    -- 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/
    
    
    

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

    Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-12T10:10:15Z

    Bruce:
    
    > Use this:
    > 
    > 	configure --enable-cassert
    
    Done, installed, and no difference in output in any way, shape, or form.
    
    > I am not sure how I would debug this even if I had access.  I guess I
    > would try the assert, and then start reviewing the long vs. int issues.
    
    I would probably want a PostGreSQL hacker working on this if that's the
    case, then.  ;)
    
    -- 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/
    
    
    

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

    Marc G. Fournier <scrappy@hub.org> — 1998-02-12T11:48:03Z

    On Thu, 12 Feb 1998, Kenji T. Hollis wrote:
    
    > > Make sure you turn on Assert checking in configure so it may give you an
    > > earlier error.
    > 
    > I have no idea of how to do set this in configure.  Configure has no
    > option to do this.
    
    	--enable-cassert
    
    
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T14:21:06Z

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

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T14:24:08Z

    > > CREATED relation pg_description with OID 17847
    > > Commit End
    > Amopen: relation pg_description. attrsize 63
    > create attribute 0 name objoid len 4 num 1 type 26
    > create attribute 1 name description len -1 num 2 type 25
    > > Amclose: relation (null).
    > > initdb: could not create template database
    > initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1
    > 
    > Installing the "#define long int" gives about 40 pages of errors.
    > 
    > > Make sure you turn on Assert checking in configure so it may give you an
    > > earlier error.
    > 
    > I have no idea of how to do set this in configure.  Configure has no
    > option to do this.
    
    Use this:
    
    	configure --enable-cassert
    
    > 
    > > These are very hard to debug because there is no running system to run
    > > tests on, and it is all very inter-related.
    > 
    > I can give access to my Alpha, but I have to talk to the person I am
    > dealing with.  I *will not* give access to this machine with a complete
    > stranger via E-Mail.
    
    610-853-3000. That is me.
    
    > 
    > > My lib/local1_template1.bki.source has the following two lines for this
    > > function:
    > > 
    > > insert OID = 949 ( mkoidname PGUID 11 f t f 2 f 911 "26 19" 100 0 0 100 foo bar)
    > > declare index pg_attribute_relid_attnam_index on pg_attribute using btree(mkoidname(attrelid, attname) oidname_ops)
    > 
    > Exact carbon-copy of mine.
    
    Good.
    
    > 
    > > That is all the ideas I have for now.  Would like to get it working.
    > 
    > So would I.  Bruce, If you would like access to the Postgres machine,
    > please feel free to give me a call tomorrow. 
    
    I am not sure how I would debug this even if I had access.  I guess I
    would try the assert, and then start reviewing the long vs. int issues.
    
    -- 
    Bruce Momjian
    maillist@candle.pha.pa.us
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T14:46:01Z

    > 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.
    
    OK, I have a new idea.  See in utils/hash/hashfn.c:tag_hash, there is
    the line:
    
                for (; keysize > (sizeof(int) - 1); keysize -= sizeof(int),key++)
                    h = h * PRIME1 ^ (*key);
    
    Now, since h is a long, shouldn't the for loop be comparing
    sizeof(long)?  However, key is an int*.  
    
    Comments?  
    
    
    -- 
    Bruce Momjian
    maillist@candle.pha.pa.us
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T14:51:52Z

    > 
    > > 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.
    > 
    > OK, I have a new idea.  See in utils/hash/hashfn.c:tag_hash, there is
    > the line:
    > 
    >             for (; keysize > (sizeof(int) - 1); keysize -= sizeof(int),key++)
    >                 h = h * PRIME1 ^ (*key);
    > 
    > Now, since h is a long, shouldn't the for loop be comparing
    > sizeof(long)?  However, key is an int*.  
    > 
    > Comments?  
    > 
    
    Never mind.  I think the code is good, but if someone sees a problem
    with longs/ints anywhere in the code, please let's discuss it.
    
    -- 
    Bruce Momjian
    maillist@candle.pha.pa.us
    
    

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

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-12T15:02:26Z

    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
    
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T16:50:51Z

    > 
    > Bruce:
    > 
    > > 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 created a small program to return the size of values.  They are:
    > 
    > Size of short: 2
    > Size of char:  1
    > Size of int:   4
    > Size of long:  8
    > 
    > Does this help?
    
    Yep.  Does anyone else run OS's with the size of long greater than int? 
    Does Dec Unix Alpha?  Are people running that?
    
    -- 
    Bruce Momjian
    maillist@candle.pha.pa.us
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T16:51:21Z

    > 
    > Bruce:
    > 
    > > OK, I have a new idea.  See in utils/hash/hashfn.c:tag_hash, there is
    > > the line:
    > > 
    > >             for (; keysize > (sizeof(int) - 1); keysize -= sizeof(int),key++)
    > >                 h = h * PRIME1 ^ (*key);
    > > 
    > > Now, since h is a long, shouldn't the for loop be comparing
    > > sizeof(long)?  However, key is an int*.  
    > 
    > How is this a problem?  *key is getting the value of the current pointer
    > of key.  This means, if key contains a string: "Ooga" and key++, then the
    > value of *key would be "o" in decimal.  This is a standard hashing
    > routine, and the problem does not lie here as far as I can see.
    
    You are right.
    
    -- 
    Bruce Momjian
    maillist@candle.pha.pa.us
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-12T16:53:13Z

    > 
    > Bruce:
    > 
    > > Use this:
    > > 
    > > 	configure --enable-cassert
    > 
    > Done, installed, and no difference in output in any way, shape, or form.
    > 
    > > I am not sure how I would debug this even if I had access.  I guess I
    > > would try the assert, and then start reviewing the long vs. int issues.
    > 
    > I would probably want a PostGreSQL hacker working on this if that's the
    > case, then.  ;)
    
    OK, it is true if I am not sure how to debug it, it is tough to see how
    you will.  I will check on the long/int issue in the source.  Can you
    try to see if the hash keys set/lookup match for mkoidname?
    
    -- 
    Bruce Momjian
    maillist@candle.pha.pa.us
    
    

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

    Marc G. Fournier <scrappy@hub.org> — 1998-02-12T16:59:19Z

    On Thu, 12 Feb 1998, Kenji T. Hollis wrote:
    
    > > I am not sure how I would debug this even if I had access.  I guess I
    > > would try the assert, and then start reviewing the long vs. int issues.
    > 
    > I would probably want a PostGreSQL hacker working on this if that's the
    > case, then.  ;)
    
    	You might want to be slightly careful here *rofl*  There are three
    ppl that I consider to be the ones that "know it all", and I don't think
    any of them have the same opinion of themselves:
    	
    	Bruce, Vadim and Thomas
    
    	We've just been blessed with a fourth that is working on
    obseleting Oracle for himself by bringing into PostgreSQL what he
    requires.
    
    	And then there are about a dozen (or more) of us that have
    knowledge of various aspects...
    
    	I think the question that should be asked is if anyone out there
    is currently working on/with PostgreSQL and a 64bit architecture, namely
    the Alpha, since the problem appears to be 64bit related, which, I don't 
    believe, any of the core currently uses, or has much knowledge of.
    
    	As has been shown over the past few hours, even, there is alot of
    knowledge and ideas that you can tap...but each of us works hard at
    maintaining our individual platforms (Vadim and I use FreeBSD, Thomas uses
    Linux, Bruce - BSDi, Darren - Aix, Andrew - Irix5/Linux, etc)...
    
    	Actually, Andrew...what is the Irix5?  64bit or 32bit still?
    
    Marc G. Fournier                                
    Systems Administrator @ hub.org 
    primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
    
    
    

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

    Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1998-02-14T01:27:25Z

    	Good grief! I don't check my email for a few days a fire fight
    over getting pgsql on Linux/Alpha ensues! :)
    	Jeff Strum has been doing some extensive work (quietly) on getting
    Linux/Alpha to run. He has gotten initdb to finish successfully and the
    regression tests are partially successful. I haven't had time to test
    things for myself, but things look promsing. Apparently there was a
    compiler define that should have been enabled, but was not due to
    different naming conventions for Linux/Alpha. Attached is the patch he
    sent me, that I have not had a chance to test yet.
    	For the future, he plans to track down and clean up the warnings
    about casting from different pointer sizes and such. I plan to help
    (mainly testing) as much as I can, but I am quite busy, and I am pretty
    sure he is too.
    	As for you, Kenji, (not to be a jerk, but instead a reality
    check) just calm down and be patient, or jump in and
    help us (i.e. email Jeff and ask him what you can do to help, or get a
    new version of pgsql, apply the patch included in this email, and report
    back to us what happens). Nothing gets done by people continously asking
    for something to be done. And anyway, porting to the alpha, a 64bit
    architecture is not simple to say the very least. Add to that, a very
    large (I think 100k+ lines of code has been stated before) and powerful
    database to port, and things reach the near impossible point. We will get
    it figured out in due time, but we don't have 50 programmers working away
    at this all day long. Then again, you are not paying anything for the
    database. So I think things are fair. :)
    	I will try and keep everyone updated a bit more regularly to head
    off fire fights like these. Thanks, and talk to you all later.
    
    PS. Kenji, where did you get that pgsql would be running on Linux/Alpha in
    Jan '98? I have never seen any such projected date!
    
    ----------------------------------------------------------------------------
    |   "For to me to live is Christ, and to die is gain."                     |
    |                                            --- Philippians 1:21 (KJV)    |
    ----------------------------------------------------------------------------
    |  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
    ----------------------------------------------------------------------------
    |               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
    ----------------------------------------------------------------------------
    

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

    Kenji T. Hollis <khollis@gawain.houston-interweb.com> — 1998-02-15T02:15:59Z

    Ryan:
    
    > 	As for you, Kenji, (not to be a jerk, but instead a reality
    > check) just calm down and be patient, or jump in and
    > help us (i.e. email Jeff and ask him what you can do to help, or get a
    > new version of pgsql, apply the patch included in this email, and report
    > back to us what happens). Nothing gets done by people continously asking
    > for something to be done. And anyway, porting to the alpha, a 64bit
    > architecture is not simple to say the very least. Add to that, a very
    > large (I think 100k+ lines of code has been stated before) and powerful
    > database to port, and things reach the near impossible point. We will get
    > it figured out in due time, but we don't have 50 programmers working away
    > at this all day long. Then again, you are not paying anything for the
    > database. So I think things are fair. :)
    
    I totally understand where you're coming from, however, I wrote over 4
    months ago reporting the problem, and was kind of brushed off like it was
    a non-issue, and I reported it twice.  Same thing twice.  Finally, I raise
    hell about it and I get a response.  I'm not impatient.  I am currently
    using msql for what I need and it seems to be getting the job done.  I
    just need somethimg much more powerful.  PostGres is much more powerful.
    
    I'm trying to help, but the first message I get was from some idiot on
    this list who told me to fix the problem myself and quit whining.  I don't
    take kindly to people who write messages like those to me, especially when
    I'm trying to help resolve an issue with the coders.  I don't deserve to
    be treated with this disrespect, and I never shoot back at any question I
    get - the most I'll do is delete the message and bite my damn tongue.
    
    So, now that you understand my position, I just wanted an update, and
    wanted to help fix the problem.
    
    > PS. Kenji, where did you get that pgsql would be running on Linux/Alpha in
    > Jan '98? I have never seen any such projected date!
    
    One of the coders told me this privately.  I wish I had saved that
    message!
    
    -- 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/
    
    
    

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-15T17:47:57Z

    > I totally understand where you're coming from, however, I wrote over 4
    > months ago reporting the problem, and was kind of brushed off like it was
    > a non-issue, and I reported it twice.  Same thing twice.  Finally, I raise
    > hell about it and I get a response.  I'm not impatient.  I am currently
    > using msql for what I need and it seems to be getting the job done.  I
    > just need somethimg much more powerful.  PostGres is much more powerful.
    > 
    > I'm trying to help, but the first message I get was from some idiot on
    > this list who told me to fix the problem myself and quit whining.  I don't
    > take kindly to people who write messages like those to me, especially when
    > I'm trying to help resolve an issue with the coders.  I don't deserve to
    > be treated with this disrespect, and I never shoot back at any question I
    > get - the most I'll do is delete the message and bite my damn tongue.
    > 
    > So, now that you understand my position, I just wanted an update, and
    > wanted to help fix the problem.
    > 
    > > PS. Kenji, where did you get that pgsql would be running on Linux/Alpha in
    > > Jan '98? I have never seen any such projected date!
    > 
    > One of the coders told me this privately.  I wish I had saved that
    > message!
    
    Ask and you shall receive.  Here is the message.  At the time of 6.2,
    Alpha/Linux was broken because the inlinine of asm() would not work
    because alpha/linux does not support local labels in asm statements, so
    if multiple lock requests were in the same C file, you had multiple
    labels with the same name, and it would not compile.
    
    This was worked on and a new fix was made, but that did not work because
    of the labels problem, so the attached fix was also broken.  The final
    solution was to move the alpha/linux lock code to a separate C file, so
    there was every feeling it would now work in 6.3.
    
    Turns out there were other problems related to compiler flags, and that
    has only recently been added to the source.  Good thing Kenji spoke up
    so we could get all the alpha/linux people together on this.
    
    ---------------------------------------------------------------------------
    
    

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

    Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1998-02-15T18:11:40Z

    On Sun, 15 Feb 1998, Kenji T. Hollis wrote:
    
    > Ryan:
    
    > I totally understand where you're coming from, however, I wrote over 4
    > months ago reporting the problem, and was kind of brushed off like it was
    > a non-issue, and I reported it twice.  Same thing twice.  Finally, I raise
    > hell about it and I get a response.  I'm not impatient.  I am currently
    > using msql for what I need and it seems to be getting the job done.  I
    > just need somethimg much more powerful.  PostGres is much more powerful.
    
    	I remember the two - three times you have posted to the list
    requesting information about running pgsql on Linux/Alpha. Each time I
    responded (politely) that it was in the works, but it was slow going due
    to lack of pgsql hackers with Alphas and Alpha experience. If you had
    wanted more information then, or felt you were brushed off, why did you
    rarely ever respond to my responses with more than a few words of
    acknowledgement? Not to pick bones here or anything, but I am just trying
    to put the record straight and defend those who have been trying to get
    the alpha port working.
    	Also, I am also currently using msql on my UDB until pgsql gets
    finished being ported. That is one of the initial reasons I got myself
    involved in this, I wanted a real (free) RDBS database for my UDB. So,
    since the pgsql hackers appeared to be "Alpha"less I jumped in and tried
    to help as best I could. 
    
    > I'm trying to help, but the first message I get was from some idiot on
    > this list who told me to fix the problem myself and quit whining.  I don't
    > take kindly to people who write messages like those to me, especially when
    > I'm trying to help resolve an issue with the coders.  I don't deserve to
    > be treated with this disrespect, and I never shoot back at any question I
    > get - the most I'll do is delete the message and bite my damn tongue.
    
    	First, let me say in the "Open Source Software" community (yes,
    notice the new name for free software), there is only a gray fuzzy line
    between the coders and the users. Here we don't ask coders to do something
    for us. Instead we ask if they have any plans/ideas on how to do something
    we want. If they don't, then it is our responsiblity to pitch in and do
    the modifications ourself. I would much rather have a piece of software
    that requires some coding on my part if they source is open and free to
    all.
    	And as for the disrespectful messages, give them a break, they had
    probably had a bad day (or maybe you did :). If it happens in a regular
    pattern, then there is a problem. A one time occurance is not worth
    worrying over.
     
    > So, now that you understand my position, I just wanted an update, and
    > wanted to help fix the problem.
    
    	Good, now that we got this mess aired out, we can get back to the
    important things, that is the actual port. Though in the future, kindly
    post a query for an update and in a little while (day or two maybe, we are
    all busy I am sure) you should recieve a response. Also, this project is
    so huge, that often the left hand does not know what the foot is doing.
    And to make matters worse, when the right hand asks about something that
    the foot is doing, the left hand jumps in to try and save the day,
    thinking that this is something totally new and undealth with. I think you
    get the picture. Just be patient I think is the best advice here.
     
    > > PS. Kenji, where did you get that pgsql would be running on Linux/Alpha in
    > > Jan '98? I have never seen any such projected date!
    > 
    > One of the coders told me this privately.  I wish I had saved that
    > message!
    
    	So do I! Though there is/was a rumor that old versions (pre 6.0)
    versions of pgsql ran fine on Linux/Alpha. But then again Linux/Alpha has
    only been around for about 1.5 years, and so the entire platform is rather
    young and still a bit unstable and changing.
    
    	Anyway... back to hacking! :)
    
    ----------------------------------------------------------------------------
    |   "For to me to live is Christ, and to die is gain."                     |
    |                                            --- Philippians 1:21 (KJV)    |
    ----------------------------------------------------------------------------
    |  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
    ----------------------------------------------------------------------------
    |               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
    ----------------------------------------------------------------------------