Greg Stark wrote:
>On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>> In order to simplify recovery at this point (enormously), it would
>> have been very helpful (at almost negligible cost), to have the name
>> of the table, the name of the columns, and the types of the
>> columns available.
>> Why don't we insert that data into the first page of a regular table
>> file after in the special data area?
>> I'd be willing to create a patch for that (should be pretty easy),
>> if nobody considers it to be a bad idea.
>There isn't necessarily one value for these attributes. You can
>rename columns and that rename may succeed and commit or fail and
>rollback. You can drop or add columns and some rows will have or not
>have the added columns at all. You could even add a column, insert
>some rows, then abort -- all in a transaction. So some (aborted) rows
>will have extra columns that aren't even present in the current table
>definition.
True.
>All this isn't to say the idea you're presenting is impossible or a
>bad idea. If this meta information was only a hint for forensic
>purposes and you take into account these caveats it might still be
>useful.
This is exactly what I meant it for. It would contain the most
recent alter table state (give or take some delay due to cache
flushes).
> But I'm not sure how useful. I mean, you can't really decipher
>everything properly without the data in the catalog -- and you have to
>premise this on the idea that you've lost everything in the catalog
>but not the data in other tables. Which seems like a narrow use case.
It happens, more often than you'd think. My client had it, I've
seen numerous google hits which show the same.
--
Stephen.
Be braver. You cannot cross a chasm in two small jumps.