Обсуждение: More Tuple Madness

Ok, just a small issue here:
I'm running:
select attname,attlen,attalign from pg_attribute where attnum>0 and attrelid
= (select oid from pg_class where relname = 'users') order by attnum;

This is to get the name, length of that attribute and the alignment.
The alignment seems to be wrong for type CHAR(1):postalcode     |     -1 | igender         |     -1 | iyearofbirth    |
    2 | s
 

Gender is what I'm looking at and I think it's supposed to be 16 bit
aligned.

Here is the data from that area of the tuple:
0B00 0000 5435 5420 3257 3600 0500 0000 4600 5000
The postal code, 32 bit aligned extracts fine:
'T5T 2W6'
This one is a female, the size is listed as 0500 or 5 (header plus the 1
char in it) It extracts as an 'F', but you can see the year of birth 80
comes only 6 bytes after the gender. Perhaps my original query for the
alignments is wrong...

-Michael

"Michael Richards" <miker@interchange.ca> writes:
> The alignment seems to be wrong for type CHAR(1):

No, the alignment is fine.  A field's align constraint says where it has
to start, not where the next field has to start.  gender starts on a
4-byte boundary and is 5 bytes long, then we have one byte wasted for
alignment of yearofbirth, then yearofbirth starts on a 2-byte boundary.
Everyone's happy.
        regards, tom lane

Oops, I guess I assumed that the alignment part was directly related to the
number of bytes until the next attribute rather than the actual alignment.

Is there any need for documentation on how this whole storage thing works?
I'd be more than willing to write it up.

-Michael

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Michael Richards" <miker@interchange.ca>
Cc: <pgsql-hackers@postgresql.org>
Sent: Sunday, December 17, 2000 1:14 PM
Subject: Re: [HACKERS] More Tuple Madness


> "Michael Richards" <miker@interchange.ca> writes:
> > The alignment seems to be wrong for type CHAR(1):
>
> No, the alignment is fine.  A field's align constraint says where it has
> to start, not where the next field has to start.  gender starts on a
> 4-byte boundary and is 5 bytes long, then we have one byte wasted for
> alignment of yearofbirth, then yearofbirth starts on a 2-byte boundary.
> Everyone's happy.
>
> regards, tom lane

Write away ...
        regards, tom lane

Is this alignment relative to the beginning of the page or tuple, or even
the tuple data area (after the tuple header)?

-Michael

> "Michael Richards" <miker@interchange.ca> writes:
> > The alignment seems to be wrong for type CHAR(1):
>
> No, the alignment is fine.  A field's align constraint says where it has
> to start, not where the next field has to start.  gender starts on a
> 4-byte boundary and is 5 bytes long, then we have one byte wasted for
> alignment of yearofbirth, then yearofbirth starts on a 2-byte boundary.
> Everyone's happy.
>
> regards, tom lane

"Michael Richards" <miker@interchange.ca> writes:
> Is this alignment relative to the beginning of the page or tuple, or even
> the tuple data area (after the tuple header)?

Well, it's absolute: on machines that care about such things, you *will*
coredump if you try to fetch an int at a non-4-byte-aligned address.

Our implementation forces tuple data area (also tuple header) to start
at a MAXALIGN'd offset in the page, and we ensure that page buffers
start at MAXALIGN'd addresses.  So the attribute access routines only
have to worry about suitable alignment of the field's offset within the
tuple data.  You'd get the same answer however you measured it, but
I think the code usually does the alignment computation on the offset
within the tuple data.
        regards, tom lane

Okay. On this particular machine, the way I was loading in the page it
properly aligns the data to the page beginning, so I used that. I now have
it extracting meaningful data from a variety of tables. The very last thing
I need to do now is figure out where the code in the source is that stores
and retrieves timestamp and datetime fields (as I'm unsure how they are
encoded).

Having written this tool which is at least the basis for a complete table
data verification program (it's written in c++) I'm wondering if there is
any chance of having it pointed to, linked to or otherwise made available?
Time-permitting I may add to it in the future, although I hope I'll never
have to use it again :)

-Michael

> Well, it's absolute: on machines that care about such things, you *will*
> coredump if you try to fetch an int at a non-4-byte-aligned address.
>
> Our implementation forces tuple data area (also tuple header) to start
> at a MAXALIGN'd offset in the page, and we ensure that page buffers
> start at MAXALIGN'd addresses.  So the attribute access routines only
> have to worry about suitable alignment of the field's offset within the
> tuple data.  You'd get the same answer however you measured it, but
> I think the code usually does the alignment computation on the offset
> within the tuple data.
>
> regards, tom lane

On Sun, Dec 17, 2000 at 06:03:34PM -0500, Michael Richards wrote:
> 
> Having written this tool which is at least the basis for a complete table
> data verification program (it's written in c++) I'm wondering if there is
> any chance of having it pointed to, linked to or otherwise made available?
> Time-permitting I may add to it in the future, although I hope I'll never
> have to use it again :)


Anyone have this code/tool Michael is talking about? I tried to contact
him directly, but one of his emails bounces, and the other has not
responded.

Ross