"Jim Buttafuoco" <[EMAIL PROTECTED]> writes:
> Thanks for the reply. here is an "ls" of my pg_clog directory. The 0402
> file, I created as per Joshua's directions.
> I might have created one too small. If so, what size do you think I should
> use.
> bda1:/usr/local/pgsql/data# ls -l pg_clog
> total 992
> -rw------- 1 postgres dba 262144 Sep 7 10:12 0000
> -rw------- 1 postgres dba 262144 Nov 12 09:57 0001
> -rw------- 1 postgres dba 262144 Dec 7 17:31 0002
> -rw------- 1 postgres dba 204800 Jan 22 13:11 0003
> -rw-r--r-- 1 postgres dba 8192 Jan 22 12:05 0402
Given that set of pre-existing files, there is no possible way that you
really had a transaction in the range of IDs that 0402 would cover.
I agree with Alvaro's theory of a corrupted tuple. In fact it seems
plausible that the error is a single high-order 1 bit and the ID that
appears to be in the range of 0402 really belonged to file 0002.
A single dropped bit sounds more like RAM flakiness than disk problems
to me, so I'd get out the memory tester programs and start looking.
As far as recovering the data goes, you can use the usual techniques for
homing in on the location of the bad tuple and getting rid of it (or try
manually patching the XID field with a hex editor...)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
