Thread: 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/ |
----------------------------------------------------------------------------
Attachment
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/ |
----------------------------------------------------------------------------