Re: Fix corrupt pg_toast table?

From: Michael Clark <codingninja(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Fix corrupt pg_toast table?
Date: 2009-08-03 19:01:28
Message-ID: bf5d83510908031201j32e98b71w53850d9c04ec760d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hello Tom and others who replied.
I appreciate the help tracking this down and eventually determining there is
no point tracking it down further.
We will do our best recovering what is accessible from the corrupt DB and an
older backup.

Thanks,
Michael.

On Fri, Jul 31, 2009 at 7:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michael Clark <codingninja(at)gmail(dot)com> writes:
> > On Fri, Jul 31, 2009 at 5:24 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> >>> Now I am getting:
> >>> ERROR: could not access status of transaction 3839923882
>
> >> How long has this database been in use? That's a very high transaction
> >> number that would only be reached on a heavily used database after a
> >> reasonably long period of use. If that's not likely than a likely
> >> possibility is that your table has been overwritten with garbage.
> >> Possibly by a filesystem bug or hardware failure.
>
> > Not really that long. The database was created in early June, and if
> that
> > is supposed to be a transaction count (3839923882), then yeah that seems
> way
> > out there.
>
> It seems certain that you're looking at corrupt data. Trashed data
> frequently manifests this way, because the transaction ID is the first
> field of tuple headers that the database can cross-check with any
> amount of rigor.
>
> At this point we know that at least two unrelated disk blocks have been
> clobbered by something (first that index page, and now this). There's
> no very good reason to think there are only two :-(. I'd bet at least
> a cheese sandwich on hardware problems. Test and fix/replace your
> hardware, then go back to your last backup (I hope you've got one).
>
> regards, tom lane
>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Kevin Grittner 2009-08-03 19:56:56 Re: PITR archive_timeout Command
Previous Message Scott Marlowe 2009-08-03 17:44:19 Re: Postgres has stopped listening on port 5432...