
I've made a little headway -- it can't find the mkoidname function
because the attributes that it looks up for the argument types have a
atttypid of 0 (see the following example):

also, other information that should be in there is not, so it makes me
suspect something wrong with insertion of attributes?  I don't know
enough to be able to see if this is affecting all attributes or just
some of them.

Does anyone have any pointers to where to check this problem out?

$4 = {attrelid = 1249, attname = {
    data = "\000\000\000\000attrelid", '\000' <repeats 19 times>}, 
  atttypid = 0, attdisbursion = 6.89648632e-314, attlen = 0, attnum = 0, 
  attnelems = 65540, attcacheoff = 0, atttypmod = -1, attbyval = -1 ', 
  attisset = -1 ', attalign = -1 ', attnotnull = -1 ', 
  atthasdef = 1 '\001'}

Wed,  4 Mar 1998 15:24:00 -0800 (PST)
Brett McCormick <brett@chicken.org>
alpha/64bit weirdness
> 
> 
> I've made a little headway -- it can't find the mkoidname function
> because the attributes that it looks up for the argument types have a
> atttypid of 0 (see the following example):
> 
> also, other information that should be in there is not, so it makes me
> suspect something wrong with insertion of attributes?  I don't know
> enough to be able to see if this is affecting all attributes or just
> some of them.
> 
> Does anyone have any pointers to where to check this problem out?
> 
> $4 = {attrelid = 1249, attname = {
>     data = "\000\000\000\000attrelid", '\000' <repeats 19 times>}, 
>   atttypid = 0, attdisbursion = 6.89648632e-314, attlen = 0, attnum = 0, 
>   attnelems = 65540, attcacheoff = 0, atttypmod = -1, attbyval = -1 ', 
>   attisset = -1 ', attalign = -1 ', attnotnull = -1 ', 
>   atthasdef = 1 '\001'}
> 
> 

I have an idea.   Edit initdb and add a '-d 3' option to each
'postgres', then run initdb.  You will see dumps of all the structures
as things are happening, I think.  Give it a try.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Wed, 4 Mar 1998 18:31:34 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness

okay.. it would appear that the bootstrap process has access to
information (about attributes) that it shouldn't, quite immediately.
i.e. when I breakpoint in DataFill, it has valid attribute structures,
but they haven't been inserted yet (?!?)  I'm not quite sure how this
works.

On Wed, 4 March 1998, at 15:24:00, Brett McCormick wrote:

> I've made a little headway -- it can't find the mkoidname function
> because the attributes that it looks up for the argument types have a
> atttypid of 0 (see the following example):
> 
> also, other information that should be in there is not, so it makes me
> suspect something wrong with insertion of attributes?  I don't know
> enough to be able to see if this is affecting all attributes or just
> some of them.
> 
> Does anyone have any pointers to where to check this problem out?
> 
> $4 = {attrelid = 1249, attname = {
>     data = "\000\000\000\000attrelid", '\000' <repeats 19 times>}, 
>   atttypid = 0, attdisbursion = 6.89648632e-314, attlen = 0, attnum = 0, 
>   attnelems = 65540, attcacheoff = 0, atttypmod = -1, attbyval = -1 ', 
>   attisset = -1 ', attalign = -1 ', attnotnull = -1 ', 
>   atthasdef = 1 '\001'}

Wed,  4 Mar 1998 16:01:05 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] alpha/64bit weirdness
> 
> 
> I've made a little headway -- it can't find the mkoidname function
> because the attributes that it looks up for the argument types have a
> atttypid of 0 (see the following example):
> 
> also, other information that should be in there is not, so it makes me
> suspect something wrong with insertion of attributes?  I don't know
> enough to be able to see if this is affecting all attributes or just
> some of them.
> 
> Does anyone have any pointers to where to check this problem out?
> 
> $4 = {attrelid = 1249, attname = {
>     data = "\000\000\000\000attrelid", '\000' <repeats 19 times>}, 
>   atttypid = 0, attdisbursion = 6.89648632e-314, attlen = 0, attnum = 0, 
>   attnelems = 65540, attcacheoff = 0, atttypmod = -1, attbyval = -1 ', 
>   attisset = -1 ', attalign = -1 ', attnotnull = -1 ', 
>   atthasdef = 1 '\001'}
> 
> 


Now that I am looking at this, I see that the attname has four bytes of
NULL's before it.  This looks like some kind of alignment error,
perhaps, like the previous entry is writing past its end and into the
this one.  Everything after the 'data' element shows garbage because it
is all shifted over.  I did add the atttypmod field to the pg_attribute
structure, and it is an int2/short.  Wonder is that threw off some
alignment, and only Alpha has a problem with it.

Please try with Assert on:

	configure --enable-cassert

Man, if I introduced this problem somehow, I am going to be upset with
myself, and I am sure a few Alpha users will join me.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Wed, 4 Mar 1998 20:33:42 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness

I just noticed that..  I recompiled & rerean initdb with assert
checking on, and, well, no change in output.  here it is.  i've stuck
in my own elog check for a value of 0 for atttypid..

suggestions?

initdb: using /usr/local/pgsql.test/lib/local1_template1.bki.source as input to create the template database.
initdb: using /usr/local/pgsql.test/lib/global1.bki.source as input to create the global classes.
initdb: using /usr/local/pgsql.test/lib/pg_hba.conf.sample as the host-based authentication control file.

We are initializing the database system with username postgres (uid=1706).
This user will own all the files and must also own the server process.

initdb: creating template database in /usr/local/pgsql.test/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql.test/data -Q template1
ERROR:  DefineIndex: woah, att->atttypid = 0 for attribute "attrelid"
ERROR:  DefineIndex: woah, att->atttypid = 0 for attribute "attrelid"
longjmp or siglongjmp function used outside of saved context
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql.test/data/base/template1


On Wed, 4 March 1998, at 20:33:42, Bruce Momjian wrote:

> Now that I am looking at this, I see that the attname has four bytes of
> NULL's before it.  This looks like some kind of alignment error,
> perhaps, like the previous entry is writing past its end and into the
> this one.  Everything after the 'data' element shows garbage because it
> is all shifted over.  I did add the atttypmod field to the pg_attribute
> structure, and it is an int2/short.  Wonder is that threw off some
> alignment, and only Alpha has a problem with it.
> 
> Please try with Assert on:
> 
> 	configure --enable-cassert
> 
> Man, if I introduced this problem somehow, I am going to be upset with
> myself, and I am sure a few Alpha users will join me.
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)

Wed,  4 Mar 1998 18:26:00 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] alpha/64bit weirdness

Why would the atttypmod affect anything before it in the struct?  I
have verified that everything is shifted over for bytes, but that
would lead be to beleive that somewhere the length of the first
attribute (Oid) is being miscalculated?  Where would the code write to
this data structure without using a pointer to actual struct for
obtaining the correct memory structure?  I checked for offsetof macro
calls that might cause this effect, to no avail..

We're a lot closer, though.. right?

On Wed, 4 March 1998, at 20:33:42, Bruce Momjian wrote:

> Now that I am looking at this, I see that the attname has four bytes of
> NULL's before it.  This looks like some kind of alignment error,
> perhaps, like the previous entry is writing past its end and into the
> this one.  Everything after the 'data' element shows garbage because it
> is all shifted over.  I did add the atttypmod field to the pg_attribute
> structure, and it is an int2/short.  Wonder is that threw off some
> alignment, and only Alpha has a problem with it.
> 
> Please try with Assert on:
> 
> 	configure --enable-cassert
> 
> Man, if I introduced this problem somehow, I am going to be upset with
> myself, and I am sure a few Alpha users will join me.
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)

Wed,  4 Mar 1998 18:28:28 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] alpha/64bit weirdness

I did that.. Postgres doesn't take the option -d 3 however, just
'-d'..  Have any idea when the pg_attribute cache is populated?

On Wed, 4 March 1998, at 18:31:34, Bruce Momjian wrote:

> I have an idea.   Edit initdb and add a '-d 3' option to each
> 'postgres', then run initdb.  You will see dumps of all the structures
> as things are happening, I think.  Give it a try.
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)

Wed,  4 Mar 1998 18:33:18 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] alpha/64bit weirdness
> 
> 
> I did that.. Postgres doesn't take the option -d 3 however, just
> '-d'..  Have any idea when the pg_attribute cache is populated?

Looks like it should:

	$ postgres -d 3 -D /u/pg/data test
	        ---debug info---
	        Quiet =        f
	        Noversion =    f
	        timings   =    f
	        dates     =    Normal
	        bufsize   =    64
	        sortmem   =    512
	        query echo =   f
	        DatabaseName = [test]
	        ----------------
	
	        InitPostgres()..
	
	POSTGRES backend interactive interface
	$Revision: 1.67 $ $Date: 1998/02/26 04:36:31 $

Not sure when it is initialized.

>
> 
> On Wed, 4 March 1998, at 18:31:34, Bruce Momjian wrote:
> 
> > I have an idea.   Edit initdb and add a '-d 3' option to each
> > 'postgres', then run initdb.  You will see dumps of all the structures
> > as things are happening, I think.  Give it a try.
> > 
> > -- 
> > Bruce Momjian                          |  830 Blythe Avenue
> > maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
> >   +  If your life is a hard drive,     |  (610) 353-9879(w)
> >   +  Christ can be your backup.        |  (610) 853-3000(h)
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Wed, 4 Mar 1998 21:45:58 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness
> Why would the atttypmod affect anything before it in the struct?  I
> have verified that everything is shifted over for bytes, but that
> would lead be to beleive that somewhere the length of the first
> attribute (Oid) is being miscalculated?  Where would the code write to
> this data structure without using a pointer to actual struct for
> obtaining the correct memory structure?  I checked for offsetof macro
> calls that might cause this effect, to no avail.

Just speculating here, but I do know that the Alpha will force alignment
within structures. So, if the structure is filled by reading a byte stream
from a file, rather than filled field-by-field, it will misalign if it has
integers < 4 bytes. During the initialization phase, the backend probably does
not go through the file manager, but does some brute-force reading of each
file on disk.

                                         - Tom


Thu, 05 Mar 1998 03:47:25 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] alpha/64bit weirdness

It couldn't!  The inital values (as far as I can tell) are either
compiled in, or fed in through the bootstrap process (text).

this would have caused problems in previous releases as well, if it is
the case.

On Thu, 5 March 1998, at 03:47:25, Thomas G. Lockhart wrote:

> > Why would the atttypmod affect anything before it in the struct?  I
> > have verified that everything is shifted over for bytes, but that
> > would lead be to beleive that somewhere the length of the first
> > attribute (Oid) is being miscalculated?  Where would the code write to
> > this data structure without using a pointer to actual struct for
> > obtaining the correct memory structure?  I checked for offsetof macro
> > calls that might cause this effect, to no avail.
> 
> Just speculating here, but I do know that the Alpha will force alignment
> within structures. So, if the structure is filled by reading a byte stream
> from a file, rather than filled field-by-field, it will misalign if it has
> integers < 4 bytes. During the initialization phase, the backend probably does
> not go through the file manager, but does some brute-force reading of each
> file on disk.
> 
>                                          - Tom

Wed,  4 Mar 1998 20:00:25 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] alpha/64bit weirdness
> 
> 
> Why would the atttypmod affect anything before it in the struct?  I
> have verified that everything is shifted over for bytes, but that
> would lead be to beleive that somewhere the length of the first
> attribute (Oid) is being miscalculated?  Where would the code write to
> this data structure without using a pointer to actual struct for
> obtaining the correct memory structure?  I checked for offsetof macro
> calls that might cause this effect, to no avail..
> 
> We're a lot closer, though.. right?

I think your dump tells up something.  Can you put a beak on the failure
line, then do a backtrace after the elog(), and start putting breaks in
the functions called on that structure, and see if we can find how that
relation name is getting messed up.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Wed, 4 Mar 1998 23:09:05 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness

I suspect that it is getting messed up in a function that has since
been called and returned..  I'll give it a shot though

On Wed, 4 March 1998, at 23:09:05, Bruce Momjian wrote:

> > We're a lot closer, though.. right?
> 
> I think your dump tells up something.  Can you put a beak on the failure
> line, then do a backtrace after the elog(), and start putting breaks in
> the functions called on that structure, and see if we can find how that
> relation name is getting messed up.
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)

Wed,  4 Mar 1998 20:58:58 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] alpha/64bit weirdness
Can you post a backtrace of the problem area.

> 
> 
> I suspect that it is getting messed up in a function that has since
> been called and returned..  I'll give it a shot though
> 
> On Wed, 4 March 1998, at 23:09:05, Bruce Momjian wrote:
> 
> > > We're a lot closer, though.. right?
> > 
> > I think your dump tells up something.  Can you put a beak on the failure
> > line, then do a backtrace after the elog(), and start putting breaks in
> > the functions called on that structure, and see if we can find how that
> > relation name is getting messed up.
> > 
> > -- 
> > Bruce Momjian                          |  830 Blythe Avenue
> > maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
> >   +  If your life is a hard drive,     |  (610) 353-9879(w)
> >   +  Christ can be your backup.        |  (610) 853-3000(h)
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Thu, 5 Mar 1998 00:12:30 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness
> 
> Can you post a backtrace of the problem area.

If the bad value is coming from the cache, can you add an elog(NOTICE)
to the cache insert code, so you can see where the bad value is going
in or out.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Thu, 5 Mar 1998 01:07:06 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness
> 
> > 
> > Can you post a backtrace of the problem area.
> 
> If the bad value is coming from the cache, can you add an elog(NOTICE)
> to the cache insert code, so you can see where the bad value is going
> in or out.
> 

Another thing you could try is to add an Assert() in the cache
input/output functions, to check for a leading null in the name, and
generate the error at that point.  Would help track it down.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Thu, 5 Mar 1998 11:31:58 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] alpha/64bit weirdness