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@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
