Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 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:
>
> It was removed because it was utterly useless.
It work
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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:
It was removed because it was utterly useless.
regards, to
John Wells wrote:
> On 12/4/07, Martijn van Oosterhout <[EMAIL PROTECTED]> 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 fil
On 12/6/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 06, 2007 at 02:35:42PM -0500, John Wells wrote:
> > A bit beyond me I'm afriad, at least at my current level with
> > postgresql. Does anyone offer a commercial tool to do this? Or, would
> > anyone be interested in doing i
On Thu, Dec 06, 2007 at 02:35:42PM -0500, John Wells wrote:
> A bit beyond me I'm afriad, at least at my current level with
> postgresql. Does anyone offer a commercial tool to do this? Or, would
> anyone be interested in doing it for a fee?
There was a tool pgfsck which could dump table data, but
On 12/5/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Not that I know of.
>
> I think the simplest thing to get your tuples back is:
>
> 1. mark the transaction that deleted them as aborted in pg_clog
> 2. reset the hint bits in the deleted tuples, or hack your postgres copy
> to ignore hint bits
John Wells wrote:
> On 12/5/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > John Wells wrote:
> >
> > > I have pg_filedump installed, but can't figure out how to dump the
> > > rows themselves. I get the equivalent of the output at the end of this
> > > post. Looking over the --help, there's noth
John Wells wrote:
> I have pg_filedump installed, but can't figure out how to dump the
> rows themselves. I get the equivalent of the output at the end of this
> post. Looking over the --help, there's nothing obvious that has gotten
> me further.
-i is the option you need; but you have to keep in
On 12/4/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 04, 2007 at 03:05:53PM -0500, John Wells wrote:
> > 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
On Tue, Dec 04, 2007 at 03:05:53PM -0500, John Wells wrote:
> 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 len
On 12/4/07, Martijn van Oosterhout <[EMAIL PROTECTED]> 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,
On Tue, Dec 04, 2007 at 02:26:21PM -0500, John Wells wrote:
> Wow...interesting idea...but to clarify, I copied the table file
> *after* the delete was run on the table. Although the data appears to
> still be there, wouldn't they be marked as deleted in some way and not
> appear in the new table e
On 12/4/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 04, 2007 at 03:38:16PM -0300, Alvaro Herrera wrote:
> > > So is it simply field width? Can one count the number of bytes based
> > > on native datatype length and determine field start/end?
> >
> > Yes. For variable length
John Wells wrote:
> On 12/4/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > John Wells wrote:
> > > On 12/4/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > > There are no field separators. Perhaps you could extract some useful
> > > > info with pg_filedump, which you can grab at
> > > > http
On Tue, Dec 04, 2007 at 03:38:16PM -0300, Alvaro Herrera wrote:
> > So is it simply field width? Can one count the number of bytes based
> > on native datatype length and determine field start/end?
>
> Yes. For variable length types, there is a 4-byte length word at the
> start of the field (unle
John Wells wrote:
> On 12/4/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > There are no field separators. Perhaps you could extract some useful
> > info with pg_filedump, which you can grab at
> > http://sources.redhat.com/rhdb
>
> So is it simply field width? Can one count the number of bytes
On 12/4/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> There are no field separators. Perhaps you could extract some useful
> info with pg_filedump, which you can grab at
> http://sources.redhat.com/rhdb
So is it simply field width? Can one count the number of bytes based
on native datatype leng
John Wells wrote:
> I've been looking through the records with a hex editor, but the
> unfortunate thing is that I either don't see consistency with field
> separators or I'm overlooking them.
There are no field separators. Perhaps you could extract some useful
info with pg_filedump, which you c
Guys,
We had a bit of a misfortunate communication breakdown here at work,
which led to a particular database not being backed up. Before we
recognized this problem, and entire database table was deleted.
I immediately copied the pgdata directory and have been able to find
the file that represent
19 matches
Mail list logo
