Обсуждение: Re: [HACKERS] PostGreSQL v6.2.1 for Linux Alpha
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/
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...
> 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/
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
> > > ...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
> --- 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
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/
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/
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
> > 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
> > 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
> 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
> > > 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
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
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/
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/
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/
> > 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
> > 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
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
> > 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
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/ | ----------------------------------------------------------------------------
Вложения
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/
> 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. ---------------------------------------------------------------------------
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/ | ----------------------------------------------------------------------------