Skip site navigation (1) Skip section navigation (2)

Re: pg_clog/0202 Error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Judith Altamirano <jaltamirano(at)correolux(dot)com(dot)mx>
Cc: PostgreSQL SQL List <pgsql-sql(at)postgresql(dot)org>
Subject: Re: pg_clog/0202 Error
Date: 2008-12-17 00:38:10
Message-ID: 18177.1229474290@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-sql
Judith Altamirano <jaltamirano(at)correolux(dot)com(dot)mx> writes:
> Hello every body I just want to know why is happening this to my data 
> base I'm doing the following query:

>      SELECT * FROM pagos where date(fecha_pago) = '2008-12-15';

> It returns the next error:

>     ERROR: can't find the transaction status 538976288
>     DETAIL: can't open file <<pg_clog/0202>> not exist file or directory

That looks a whole lot like a corrupt-data problem --- not least because
538976288 = 0x20202020, ie four ASCII spaces.  It would seem that
something overwrote one of your data rows with text.  (The reason you
get this message rather than something more useful is that the
transaction ID number is the first part of the row data that Postgres
can check with any degree of strictness.)

If I had to bet I'd bet first on a kernel bug that caused a page of some
text file to get dumped into your Postgres data file.  It's also
possible that you had a hardware-level glitch that led the disk drive to
write data in the wrong place.  Make sure your system software is up to
date, and then run some disk diagnostics.

If you don't have a database backup you can revert to, look through the
PG list archives for advice about recovering from corrupt data.  That
particular row is gone beyond recall, but you should be able to clear
out the damaged page(s) and at least recover the rest of your table.

			regards, tom lane

In response to

pgsql-sql by date

Next:From: Louis-David MitterrandDate: 2008-12-17 06:51:11
Subject: archiving or versioning data?
Previous:From: Erik JonesDate: 2008-12-17 00:33:21
Subject: Re: Way to eliminate pg_dump activity from pg_stat_all ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group