Re: pg_rawdump

Tom Lane wrote:
>"Stephen R. van den Berg" <srb(at)cuci(dot)nl> writes:
>> 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?

>(1) it wouldn't necessarily fit

Three viable options (pick any one, depending on other criteria):
a. If it doesn't fit at first, drop columnnames, and try again.
b. If necessary extend it into the special data area of the following page
(repeat until you stored everything).
c. Simply put in what fits and discard the rest.

Please note that the information in there is purely informational
and of a best-effort nature. It is not required for regular operation.
It should have close to no performance impact in the normal use case.
It is meant to help with forensics if the catalog is damaged or lost,
and you still want to attempt to recover most of the data contained
in this tablefile.

>(2) what are you going to do to maintain it during ALTER TABLE?

Simply pick a point in time where it will be blatantly overwritten.
Either at reception of the command, or at commit time, whatever
is more convenient to implement. It's a best effort service, it
is not a problem if we get it wrong sometimes due to wildly
overlapping alter table/commit/rollback sequences.

>(3) if there are any custom types involved, you're still lost.

Yes, this is a not a complete solution, it's a valid attempt at
making forensics a lot easier in the common case at virtually
no cost to the running system.
--
Stephen.

Life is that brief interlude between nothingness and eternity.