Re: pg_rawdump - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_rawdump
Date
Msg-id AANLkTinJuGiRqi9CNtspNwpwYy9rSFSByCfKQ5WRgozW@mail.gmail.com
Whole thread Raw
In response to Re: pg_rawdump  ("Stephen R. van den Berg" <srb@cuci.nl>)
Responses Re: pg_rawdump
List pgsql-hackers
On Wed, Oct 20, 2010 at 5:30 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
> 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.

I don't think we should shrink the amount of usable space by 4 bytes
per block and break on-disk compatibility just to make it easier to
reconstruct corrupted tables.

I'm pretty dubious about the proposal to stuff an otherwise-useless
metapage in every heap, too.  If you have many small tables, you just
doubled your disk utilization - worse than that, maybe, if some of
them are empty.  If we needed a metapage anyway and had extra space to
play with, stuffing some useful forensic information in there might be
worthwhile, but I have a hard time thinking that forensics alone is a
sufficient justification for such a change.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: max_wal_senders must die
Next
From: Greg Stark
Date:
Subject: Re: default_statistics_target WAS: max_wal_senders must die