From: | "John Wells" <jb(at)sourceillustrated(dot)com> |
---|---|
To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, "John Wells" <jb(at)sourceillustrated(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Recovering data via raw table and field separators |
Date: | 2007-12-04 19:26:21 |
Message-ID: | 44dddf400712041126o143f23acxc630cce35ee19aba@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/4/07, Martijn van Oosterhout <kleptog(at)svana(dot)org> 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 types, there is a 4-byte length word at the
> > start of the field (unless you are using 8.3 which introduces more
> > compact representations in some cases).
>
> And NULLs are skipped entirely. They are represented in the null-bitmap
> at the beginning of the tuple.
>
> What sometimes works is creating a new table with the exact same
> structure, shutting down the postmaster and copying the old table over
> the new one. If it's the same cluster and the clog/xlog are still there
> it might work.
>
> Have a nice day,
Martijn,
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 even if the copy worked?
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-12-04 19:28:55 | Re: Recovering data via raw table and field separators |
Previous Message | Gauthier, Dave | 2007-12-04 19:21:43 | Re: Tuning configuration |