Thread: 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