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/

As v6.2.1 is >4mos old, have you tried using the v6.3beta?

Not quite sure where I can find 6.3beta ... if you're talking about the
snapshot, that's what I tried.

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

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/

As v6.2.1 is >4mos old, have you tried using the v6.3beta?

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

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

As v6.2.1 is >4mos old, have you tried using the v6.3beta?

Not quite sure where I can find 6.3beta ... if you're talking about the
snapshot, that's what I tried.

Ah, okay, then your subject was a little misleading :(

Have you tried running gdb against your core dump?

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

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

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/

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

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

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

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.

I saw this in hsearch.h:

typedef struct element
{
unsigned long next; /* secret from user */
long key;
} ELEMENT;

typedef unsigned long BUCKET_INDEX;

I wonder is this is the problem. Should then be ints. It would be
great if you could read the hash value going in for mkoidname function,
and then see if the same key is being used for the lookup. Perhaps some
elog(NOTICE) lines near the hash function would tell you this.

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