pg_rawdump - Mailing list pgsql-hackers

From Stephen R. van den Berg
Subject pg_rawdump
Date
Msg-id 20101019201223.GA15684@cuci.nl
Whole thread Raw
Responses Re: pg_rawdump  (Greg Stark <gsstark@mit.edu>)
Re: pg_rawdump  (Tom Lane <tgl@sss.pgh.pa.us>)
Table description in the data file (Re: pg_rawdump)  ("Stephen R. van den Berg" <srb@cuci.nl>)
List pgsql-hackers
I spent yesterday writing a new tool pg_rawdump (which will be released as
open source in due course), which takes the table files in an arbitrary
pgsql database, and is able to transform those back into tables (including
toast values).

In the course of doing this (a customer needed it because he only had a
copy of those files, the pg_clog etc. dirs were lost), I noticed that
there are two problems which complicate recovery (needlessly):
a. It takes some guesswork to find out which file corresponds with  which table.
b. In order to recover the table content, it is (obviously) necessary  to correlate with the original table definition,
whichobviously  is lost with the rest of the information.
 

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.
-- 
Stephen.


pgsql-hackers by date:

Previous
From: Terry Laurenzo
Date:
Subject: Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
Next
From: Andrew Dunstan
Date:
Subject: Re: WIP: extensible enums