Bruce Momjian <maillist@candle.pha.pa.us>
> 
> > Bruce Momjian <maillist@candle.pha.pa.us>
> > 
> > > 
> > > > On Mon, Aug 24, 1998 at 03:18:28PM -0400, Bruce Momjian wrote:
> > > > > Would someone check a running 6.3.2 system and let me know if there 
are
> > > > > any blank attalign values?  It think you will find that there are.  
The
> > > > > current patch fixes that.
> > > > 
> > > > echo "select * from pg_attribute where attalign != 'i' and attalign !=
> > > > 'c'and attalign != 'd' and attalign!='s';"|psql template1
> > > 
> > > Yikes.  Good thing that is fixed now.
> > > 
> > 
> > Another interesting thing?
> > 
> > (appologies for the width)
> > 
> > I would half expected attalign to be 'd' for all these.
> > 
> > I'm not sure how the values get there though!!
> 
> Can you research what the proper value should be.  We have char/varchar
> set to 'i', but others set to 'd'.  What should be the proper value.  Is
> 'd' and 'i' alignment the same on our supported platforms.  Does a char
> field of length 32 align on int, but a double align on double differently.

Bruce,

I'm probably not the best person to explain this or determine what the
correct values are. I'm not sure I even understand how things work
myself.

I think we require the alignment definitions because we are storing
tuples as structures on disk and reading and writing them as raw
data. Hence, when we read from disk into one of the FormData structs
we need to ensure that the data reads in with the correct alignment.

(If you declare a struct in C it may occupy more bytes than you
 imagine due to alignment.)
 
Reading by 'C' book here.

	Don't assume, however, that the size of a structure is the sum
	of the sizes of it's members. Because of alignment requirements
	for different objects, there may be "holes" in a structure.
	Thus, for instance, if a char is one bye and an int four bytes,
	the structure
	
		struct {
			char c;
			int i;
		};
		
	might well require eight bytes not five.
	
I guess we need to ensure that if we write this struct to disk we 
put the bytes <char><pad><pad><pad><int><int><int><int> into the
block.

When we read the data back into the structure we get a valid alignment.

I think this padding works by adding bytes to the previous field so that
when the current field is written is is on the right boundary.

Does this make sense, or am I barking up the wrong tree?

Keith.


 


Thu, 27 Aug 1998 22:49:39 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Re: [HACKERS] initdb problem
> I think this padding works by adding bytes to the previous field so that
> when the current field is written is is on the right boundary.
> 
> Does this make sense, or am I barking up the wrong tree?

You are correct.  I just don't know what the alignment issues are of
double vs. int for our various character types.

This is more of an academic question, because your Sparc problem is
probably not that, but something else that I can reproduce now.


-- 
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, 27 Aug 1998 20:24:20 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
>
> > I think this padding works by adding bytes to the previous field so that
> > when the current field is written is is on the right boundary.
> >
> > Does this make sense, or am I barking up the wrong tree?
>
> You are correct.  I just don't know what the alignment issues are of
> double vs. int for our various character types.
>
> This is more of an academic question, because your Sparc problem is
> probably not that, but something else that I can reproduce now.
>
>
> --
> Bruce Momjian                          |  830 Blythe Avenue

Hi all,

    I  don't know if this is really related to the initdb problem
    discussion (haven't followed it enough). But seems so because
    it  fixes  a  damn  problem  during  index tuple insertion on
    CREATE TABLE into pg_attribute_relid_attnum_index.

    Anyway - this bug was really hard to find. During startup the
    relcache  reads  in  some  prepared  information  about index
    strategies from a file and then  reinitializes  the  function
    pointers  inside  the  scanKey data.  But for sake it assumed
    single attribute index tuples (hasn't that changed recently).
    Thus not all the strategies scanKey entries where initialized
    properly,  resulting  in  invalid  addresses  for  the  btree
    comparision functions.

    With  the  patch  at  the  end  the  regression  tests passed
    excellent except for the sanity_check that crashed at  vacuum
    and the misc test where the select unique1 from onek2 outputs
    the two rows in different order.

    Bruce, could you please apply it?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #


*** relcache.c.orig	Fri Aug 28 05:03:02 1998
--- relcache.c	Fri Aug 28 05:02:12 1998
***************
*** 1982,1991 ****
  #define SMD(i)	strat[0].strategyMapData[i].entry[0]
  
  		/* have to reinit the function pointers in the strategy maps */
! 		for (i = 0; i < am->amstrategies; i++)
  			fmgr_info(SMD(i).sk_procedure,
  					  &(SMD(i).sk_func));
! 		SMD(i).sk_nargs = SMD(i).sk_func.fn_nargs;
  
  
  		/*
--- 1982,1992 ----
  #define SMD(i)	strat[0].strategyMapData[i].entry[0]
  
  		/* have to reinit the function pointers in the strategy maps */
! 		for (i = 0; i < am->amstrategies * relform->relnatts; i++) {
  			fmgr_info(SMD(i).sk_procedure,
  					  &(SMD(i).sk_func));
! 			SMD(i).sk_nargs = SMD(i).sk_func.fn_nargs;
! 		}
  
  
  		/*

Fri, 28 Aug 1998 05:24:18 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] initdb problem
> 
> Hi all,
> 
>     I  don't know if this is really related to the initdb problem
>     discussion (haven't followed it enough). But seems so because
>     it  fixes  a  damn  problem  during  index tuple insertion on
>     CREATE TABLE into pg_attribute_relid_attnum_index.
> 
>     Anyway - this bug was really hard to find. During startup the
>     relcache  reads  in  some  prepared  information  about index
>     strategies from a file and then  reinitializes  the  function
>     pointers  inside  the  scanKey data.  But for sake it assumed
>     single attribute index tuples (hasn't that changed recently).
>     Thus not all the strategies scanKey entries where initialized
>     properly,  resulting  in  invalid  addresses  for  the  btree
>     comparision functions.
> 
>     With  the  patch  at  the  end  the  regression  tests passed
>     excellent except for the sanity_check that crashed at  vacuum
>     and the misc test where the select unique1 from onek2 outputs
>     the two rows in different order.
> 
>     Bruce, could you please apply it?
Jan, this is great.  It would have taken me a long time to find this. 
Why my platform did not fail is a real mystery.

Patch applied.  I am looking at the vacuum problem now.

-- 
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, 27 Aug 1998 23:37:08 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
> Jan, this is great.  It would have taken me a long time to find this.
> Why my platform did not fail is a real mystery.
>
> Patch applied.  I am looking at the vacuum problem now.
>
> --
> Bruce Momjian                          |  830 Blythe Avenue

Bruce,

    Seems   that   the   addresses   that   where  assigned  when
    pg_internal.init is created (don't  know  exactly  when  this
    happens)  are  the  same  as they should be later (when it is
    read into). I absolutely don't know why  they  are  different
    between  these  two  situations  at all, it are all addresses
    from builtin functions, and the postgres image is allways the
    same  one.  So  I'm a little confused about it. But these are
    the facts gdb told me.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Fri, 28 Aug 1998 05:52:45 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] initdb problem