Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> > Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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
> > > > > any blank attalign values? It think you will find that there are.
> > > > > 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.
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
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,
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
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?
pgsql-hackers by date
|Next:||From: jb||Date: 1998-08-28 00:11:09|
|Previous:||From: Matthew N. Dodd||Date: 1998-08-27 21:45:21|
|Subject: FOREIGN KEY revisited|