Re: pg_clog problem (PG version 7.4.5)

I was able to copy the table over to a temp table and truncate it with only a little loss. I will be able to recover
the lost data from backup so no big deal. I will have to schedule downtime to do the memory test with the "big" snow
storm it will not be until monday night.

thanks for the help
Jim

---------- Original Message -----------
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jim(at)contactbda(dot)com
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Sent: Sat, 22 Jan 2005 13:41:04 -0500
Subject: Re: [HACKERS] pg_clog problem (PG version 7.4.5)

> "Jim Buttafuoco" <jim(at)contactbda(dot)com> 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
------- End of Original Message -------