Re: Recovering data via raw table and field separators

John Wells wrote:
> On 12/4/07, Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> > Ah sorry, I though you meant de table was dropped or the database was
> > deleted. If you actually ran a DELETE FROM on the table, then yes
> > they'll all be marked deleted.
>
>
> So, given a database table file that still has records in it, and
> given the fact that these records could be parsed and displayed if the
> proper utilty knew how to read the various data structures used to
> denote field and record length, is there no utility to do this? I
> seems that it would be fairly straight forward to somehow read the
> records, yet to pay no mind to the deleted flag (or whatever mechanism
> postgresql uses to mark them as deleted).

We used to have the C defined MAKE_EXPIRED_TUPLES_VISIBLE that would
make deleted rows visible, but it seems it was removed in this commit as
part of a restructuring:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/time/tqual.c.diff?r1=1.95;r2=1.96;f=h

Sun Sep 3 15:59:39 2006 UTC (15 months, 1 week ago) by tgl
Branches: MAIN
Diff to: previous 1.95: preferred, colored
Changes since revision 1.95: +100 -66 lines

Arrange for GetSnapshotData to copy live-subtransaction XIDs from the
PGPROC array into snapshots, and use this information to avoid visits
to pg_subtrans in HeapTupleSatisfiesSnapshot. This appears to solve
the pg_subtrans-related context swap storm problem that's been reported
by several people for 8.1. While at it, modify GetSnapshotData to not
take an exclusive lock on ProcArrayLock, as closer analysis shows that
shared lock is always sufficient.
Itagaki Takahiro and Tom Lane

Not sure if we should re-add it for later use.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +