From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Francisco Reyes <lists(at)stringsutils(dot)com> |
Cc: | PostgreSQL general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Corrupted DB? could not open file pg_clog/#### |
Date: | 2006-08-01 09:05:48 |
Message-ID: | 20060801090548.GA30427@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jul 31, 2006 at 06:09:33PM -0400, Francisco Reyes wrote:
> Martijn van Oosterhout writes:
>
> >That's when you've reached the end of the table. The point is that
> >before then you'll have found the value of N that produces the error.
>
> Will be a while.. my little python script is doing under 10 selects/sec...
> and there are nearly 67 million records. :-(
Naturally you'd do a binary search. That'd take a maximum of about
log2(67 million) = about 26 scans.
Once you find it you should be able to identify the ctid. You may be
able to delete it.
> >It will rollback all pending transactions. The point is that it's
> >looking for information about transactions that were committed. This is
> >usually a memory or disk error.
>
> So, should it be safe to create the file and fill it up with 256K zeros?
For a certain value of "safe". It get the system running, but there's
no guarentees about the data in it...
> At the rate my script is going.. it's going to take a very long time to
> find out where the problem is. If I have a dump.. any usefull info I can
> take from the point the dump stopped?
That gives you the place in the file where it broke...
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-08-01 09:14:09 | Re: Error in PostgreSQL query with psycopg |
Previous Message | Roman Neuhauser | 2006-08-01 08:32:29 | Re: Triggers in Postgres |