Re: pg_clog problem (PG version 7.4.5)

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>
Subject: Re: pg_clog problem (PG version 7.4.5)
Date: 2005-01-22 18:41:04
Message-ID: 24375.1106419264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2005-01-22 18:52:05 Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED
Previous Message Jim Buttafuoco 2005-01-22 18:14:41 Re: pg_clog problem (PG version 7.4.5)