(Updated) Table File Format
От | Michael Richards |
---|---|
Тема | (Updated) Table File Format |
Дата | |
Msg-id | 020401c06561$00d4e800$0200a8c0@digitallis обсуждение исходный текст |
Ответы |
Re: (Updated) Table File Format
|
Список | 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 по дате отправления: