(Updated) Table File Format - Mailing list pgsql-hackers

From Michael Richards
Subject (Updated) Table File Format
Date
Msg-id 020401c06561$00d4e800$0200a8c0@digitallis
Whole thread Raw
Responses Re: (Updated) Table File Format
List pgsql-hackers
I need a little help on the format of the postgres tables.
I've got this wonderfully corrupted database where just about everything isfubar. I've tried a number of things to get
itback using postgres andrelated tools with no success. It looks like most of the data is there, butthere may be a
smallamount of corruption that's causing all kinds ofproblems.
 
I've broken down and begin development of a tool to allow examination of
thedata within the table files. This could actually be useful for recoveringand undoing changes (or at least until the
row-reusecode goes intoproduction).
 
I've been hacking the file format and trying to find stuff in the source
anddocs as much as possible, but here goes...
a) tuples cannot span multiple pages (yet).b) the data is not platform independant??? Ie the data from a sun
looksdifferentfrom an intel?
 
For every page, I see that the first 2 words are for the end of the tuplepointers and the beginning of the tuple data.
What are the next 2 words used for? In all my cases they appear to be set
to0x2000.
Following that I find the 2 word tuple pointers.
The first word appears to be the offset in the page where the tuple can be
found but the MSB has to be stripped off (haven't found it's function in the
source yet).
The second is the transactionid that, if comitted gives this tuple
visibility???

Are these tuple pointers always stored in order of last to first? Or should
I be loading and sorting them according to offset?
Now on to the tuple data... I have my tool to the point where it extracts
all the tuple data from the table, but I haven't been able to find the place
in the postgres source that explains the format. I assume a tuple contains a
number of attributes (referencing pg_attribute). Those not found in the
tuple would be assumed to be NULL.
Since I'm ignoring transaction ids right now, I'm planning on extracting
all
the tuple and ordering them by oid so you can see all the comitted and
uncomitted changes. I may even make it look good once I've recovered my
data...
-Michael





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: left join bug?
Next
From: Alfred Perlstein
Date:
Subject: Re: Idea for reducing planning time