John Wells wrote: > On 12/4/07, Martijn van Oosterhout <kleptog@xxxxxxxxx> 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
