Re: Recovering data via raw table and field separators

John Wells wrote:
> On 12/4/07, Martijn van Oosterhout <kleptog@svana.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

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