Re: Shit happens - Mailing list pgsql-general

From Radosław Smogura
Subject Re: Shit happens
Date
Msg-id 201101021410.18946.rsmogura@softperience.eu
Whole thread Raw
In response to Re: Shit happens  (Alban Hertroys <dalroi@solfertje.student.utwente.nl>)
List pgsql-general
Hi,

I can only think, You could try to parse page files. If you didn't do VACCUM
FULL you could try to restore it, if those rows was not overwritten after
VACCUM (normal). Maybe some "internal" guys can give you answer (if e.g.
VACCUM (nomral) zeros row).

The programm to restore will bo so tricky as file system undelete, and it will
have same requirements as.

Here I found some link (I gooled "postgresql find deleted tuples"):

http://postgresql.1045698.n5.nabble.com/Restore-deleted-rows-td2005963.html

I think I saw quite interesting idea of "trash" for vaccumed tuples.

Kind regards,
Radosław Smogura
http://www.softperience.eu


Alban Hertroys <dalroi@solfertje.student.utwente.nl> Sunday 02 January 2011
13:35:29
> On 2 Jan 2011, at 13:19, Dick Kniep wrote:
> > Thanks for the clear answer. However, this is the simple answer that is
> > also in the manual. Yes I know it is not directly possible to get that
> > data, but I am quite desparate to get the data back. If one way or
> > another the data is (except for the 4 days we really have no data for)
> > accessible, we will write a program to recover the data into the
> > production database. So if anyone of you knows about a way to access the
> > actual data in the WAL file (or a reference where to find enough
> > information to do this) I would be very happy.
>
> I suppose you did already try restoring that dump and applying the log
> files to it and that failed?
>
> Alban Hertroys
>
> --
> Screwing up is an excellent way to attach something to the ceiling.
>
>
> !DSPAM:737,4d20711d11541020214904!

pgsql-general by date:

Previous
From: Joel Jacobson
Date:
Subject: Finding recursive dependencies
Next
From: Jeremy Harris
Date:
Subject: Re: problem updating from form