Re: Clues about tables fileformat

The short answer is that you will need to modify tqual.c and have some
of those routines return 'true' all the time. I think
HeapTupleSatisfiesSnapshot() is the one you want. Recompile and install
and a query on the table will show you the data, or at least it should.

Make sure you back up your /data file before trying this and restore
them once you have COPY'ed out the table you want.

---------------------------------------------------------------------------

Miguel A. =?ISO-8859-1?Q?Ar=E9valo?= wrote:
> First, the embarrasing thing, in summary, deleted table, no backup at
> all, neither vacuum so ended with a pretty file with all my data but no
> clever way to access them.
>
> I've search for this question in the archives and only find a reference
> to "The Tao of Backup" which enlightened me, and will be very useful for
> future reference but doesn't solve my present problem. Also find some
> references for a "not so hard to make" recover utility so...
>
> I'm not a bad C and PERL hacker so I'm trying to contribute this utility
> but havent't found any doc about this file format (well, yes,
> http://developer.postgresql.org/docs/postgres/page.html, Chapter 7. Page
> Files, but it's somehow cryptical), I've scanned also
> some of the source code but haven't been able to find any information
> that helps me (I've only studied some parts of the fti contrib module
> before), also tried to do some rev. eng. but this is no the way to go so
> I would be grateful is someone can:
>
> - Point me to some more detailed developer doc about this file format.
>
> - Point me to some part of the source code that could be of help, please
> be precise because I'm not very familiar with the tree.
>
> - Or even explain, in summary, something about this file format, or some
> of the bytes needed for me to write this tool.
>
> - Of course, if someone has made or started this tool I will be very
> happy to receive an URL to a .tar.gz ;-) .
>
> On another point, I've been thinking about this tool, and will accept
> hints about this proccess:
>
> - The tool will receive the schema of the table and a copy of the file
> which stores this table, as far I know the schema is not stored in the
> table data file.
>
> - After scanning the file will print a (sorted or filtered by
> transaction id or number of altered rows) list of transactions.
>
> - Ask for a trasaction id and store all the data on a new .sql file much
> like the one generated from a pg_dump.
>
> I think that this is fairly feasible and practical, am I wrong?
>
>
> So, thanks in advance for your help, and thank you all for this killer
> application.
>
> PS: Oops, forgot something, I'm talkin about PG 7.1 after that I will
> port it to 7.2 if someone finds it usefull.
>
> Miguel A. Ar?valo
> marevalo(at)marevalo(dot)net
> ____________________________________________
> Biblios.Org: All your Book Are Belong to Us.
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026