Re: Clues about tables fileformat

Amazing,

although my computer runs only free software for many months (and partly
for many years) I still get shocked when I get a real useful answer from
a mailing list, from one of the real men, that really solves real
problems with a piece of software in less time that Microsoft Support
used to last to pick up the phone in my (now happily far behind) days of
NT, Exchange and M$ SQL Server administrator.

Of course thanks a lot for the quick and precise answer. Of course, it
worked.

But I'm still interested in working in that recovery tool (of course
with less pressure), as it would be very useful, not only for this kind
of "problems" but with problems with corruption (with some love) and
recovering data without stopping the database (or with minimum downtime)
nor installing PostgreSQL on another machine, so I'm still interested in
any doc or information of help in order to implement it.

And thanks again for this excellent (o)RDBMS, I'm dying to see that
wonderful eager replication system that is being integrated into 7.3 and
later

Miguel A. Arévalo
marevalo(at)marevalo(dot)net
____________________________
Biblios.Org: Save the trees!

El sáb, 02-03-2002 a las 19:18, Bruce Momjian escribió:
>
> 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:

Blah, blah, blah ...

> > 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