Thread: Re: [HACKERS] initdb problem
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.
> 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)
>
> > 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;
! }
/*
> > 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)
> 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) #