Success, of sorts. I was able to retrieve 90% the corrupted data by
dumping the heap file. Many thanks to those who replied with helpful
suggestions.
If you're interested in detail then read on. Otherwise, don't bother.
The data was still in the table -- I could see it using a hex editor.
This
On Tue, Jun 23, 2009 at 2:05 PM, Gus
Gutoski wrote:
> Success, of sorts. I was able to retrieve 90% the corrupted data by
> dumping the heap file. Many thanks to those who replied with helpful
> suggestions.
>
> If you're interested in detail then read on. Otherwise, don't bother.
>
> The data w
On Sun, Jun 14, 2009 at 10:32 AM, Gus
Gutoski wrote:
> Merlin Moncure wrote:
>>> postgresql 8.1 supports pitr archiving. you can
>>> do continuous backups and restore the database to just before the bad
>>> data.
>
> I tried using point-in-time-recovery to restore the state of the
> database imme
On Sun, 2009-06-14 at 10:32 -0400, Gus Gutoski wrote:
> 0. Shortly after the corruption on June 9, 2009, I shut down the
> server and backed up the entire data directory. The recovery
> procedure described herein begins with this file system backup.
> 1. The most recent non-corrupted snapshot of
Merlin Moncure wrote:
>> postgresql 8.1 supports pitr archiving. you can
>> do continuous backups and restore the database to just before the bad
>> data.
I tried using point-in-time-recovery to restore the state of the
database immediately before the corruption. It didn't work, but it
was quit
> >> It's a classic story. I'm volunteering about one day per month for
> >> this project, learning SQL as I go. Priority was always given to
> the
> >> "get it working" tasks and never the "make it safe" tasks. I
> had/have
> >> grandiose plans to rewrite the whole system properly after I
> gra
On Thu, Jun 11, 2009 at 1:32 PM, Chris Spotts wrote:
>
>> It's a classic story. I'm volunteering about one day per month for
>> this project, learning SQL as I go. Priority was always given to the
>> "get it working" tasks and never the "make it safe" tasks. I had/have
>> grandiose plans to rewr
> It's a classic story. I'm volunteering about one day per month for
> this project, learning SQL as I go. Priority was always given to the
> "get it working" tasks and never the "make it safe" tasks. I had/have
> grandiose plans to rewrite the whole system properly after I graduate.
> Unfort
Thanks for the replies.
Tom Lane wrote:
> This being 8.1, if you haven't turned on autovacuum there is some chance
> of that.
Unfortunately, autovacuum was on. I don't recall ever turning it on,
but this database is over two years old; it's possible that I blindly
followed advice from pgAdmin or
On Wed, Jun 10, 2009 at 12:49 PM, Gus
Gutoski wrote:
> Hi,
>
> I'm a noob who failed to properly sanitize incoming data from the
> front end. As a result, a poor hapless user managed to smuggle in a
> malicious UPDATE statement that corrupted every single record in a
> 7+ table. Only 3 fields
On Wed, Jun 10, 2009 at 12:49 PM, Gus
Gutoski wrote:
> Of course, the double minus sign comments out the rest of the line and
> the statement is left dangling, looking for a terminating semicolon.
SQL statements are not terminated with semi-colons. The semi-colon is
used in the psql shell to indi
Gus Gutoski writes:
> Naturally then, *every* record in the database has its "foreign_id"
> field set to 2 and its "coin" field set to 50. I *really* need to
> recover that "foreign_id" field. (As its name suggests, that field is
> a foreign key into a different table.)
Well, in principle you c
Hi,
I'm a noob who failed to properly sanitize incoming data from the
front end. As a result, a poor hapless user managed to smuggle in a
malicious UPDATE statement that corrupted every single record in a
7+ table. Only 3 fields were corrupted and of those only one is
vital. But it's REALLY
13 matches
Mail list logo
