Tom Lane wrote:
>Aidan Van Dyk <aidan@highrise.ca> writes:
>> If we're looking to have any sort of "out of catalog" documentation of
>> table storage format, what about just having a new relation fork that
>> just "appends" each and every change made to the table formats,
>> including ones rolled back, etc.
I presume that means that all tables changes are appended to a single
central file per database? That would be a bad idea, because in the
typical problem scenario, losing this new catalogue, basically creates
the same problem. It would be preferable to keep the information
tied in with the actual table(file) it concerns.
>[ thinks for a bit... ] Perhaps we could stick some sort of unique
>ID into tables, which could be correlated to the same unique ID
>appearing in a metadata fork.
Ideal would be: put the table-oid inside the header of each page
(either in the official header, or in the special area).
This way even lost blocks can be correlated to the same table.
I'd still vote for the latest known table definition in the first
page. It's by no means perfect, but it will help 99% of all
salvage attempts by an order of magnitude.
>[ thinks some more... ] Of course, at this point you have to start
>asking why the metadata fork should be thought to be any more reliable
>than the system catalogs.
Quite. Which is why I wanted the best-effort latest version of the
table description in the first page of the tablefile instead.
>> Make this relation fork append only,
>> and dump a completely new set of metadata to it each and every ALTER
>> TABLE.
>You can bet that there'll be somebody out there who whines because their
>app does lots and lots of repeated ALTER TABLEs, and so the metadata fork
>grows forever. I think we'd have to be a bit smarter than this.
Which means we come full circle and have to conclude that doing anything
comprehensive is too invasive for normal operations; best-effort is
all a forensics operation wants or can hope for.
--
Stephen.
Life is that brief interlude between nothingness and eternity.
