Re: pg_clog problem (PG version 7.4.5)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_clog problem (PG version 7.4.5)
Дата
Msg-id 24375.1106419264@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_clog problem (PG version 7.4.5)  ("Jim Buttafuoco" <jim@contactbda.com>)
Ответы Re: pg_clog problem (PG version 7.4.5)  ("Jim Buttafuoco" <jim@contactbda.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jim Buttafuoco"
Дата:
Сообщение: Re: pg_clog problem (PG version 7.4.5)
Следующее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED