Re: pg_clog problem (PG version 7.4.5)

Поиск
Список
Период
Сортировка
От Jim Buttafuoco
Тема Re: pg_clog problem (PG version 7.4.5)
Дата
Msg-id 20050122192303.M5951@contactbda.com
обсуждение исходный текст
Ответ на Re: pg_clog problem (PG version 7.4.5)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: Alvaro Herrera <alvherre@dcc.uchile.cl>, "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Sat, 22 Jan 2005 13:41:04 -0500
Subject: Re: [HACKERS] pg_clog problem (PG version 7.4.5) 

> "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
> 
> ---------------------------(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 -------



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED