Re: pg_clog problem (PG version 7.4.5) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_clog problem (PG version 7.4.5)
Date
Msg-id 24375.1106419264@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_clog problem (PG version 7.4.5)  ("Jim Buttafuoco" <jim@contactbda.com>)
Responses Re: pg_clog problem (PG version 7.4.5)  ("Jim Buttafuoco" <jim@contactbda.com>)
List pgsql-hackers
"Jim Buttafuoco" <jim@contactbda.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


pgsql-hackers by date:

Previous
From: "Jim Buttafuoco"
Date:
Subject: Re: pg_clog problem (PG version 7.4.5)
Next
From: Euler Taveira de Oliveira
Date:
Subject: Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED