Re: table corrupted - Mailing list pgsql-hackers
From | Joshua D. Drake |
---|---|
Subject | Re: table corrupted |
Date | |
Msg-id | 1256253367.2821.10.camel@jd-desktop.unknown.charter.com Whole thread Raw |
In response to | table corrupted (João Eugenio Marynowski <joaoem@gmail.com>) |
Responses |
Re: table corrupted
Re: table corrupted |
List | pgsql-hackers |
On Thu, 2009-10-22 at 14:28 -0200, João Eugenio Marynowski wrote: > Hi > Repair? Not likely. Get past? Maybe. set zero_damaged_pages to on; vacuum verbose; I would do a hardware check too. Joshua D. Drake > Can someone help me how to repair the problem below, I'm using > Postgres 8.2.5: > - after appeared the erros below in selects, vacuum and dump in one > table: > 2009-10-16 16:07:06 BRT 192.168.0.87 ERROR: could not access status > of transaction 29024764 > 2009-10-16 16:07:06 BRT 192.168.0.87 DETAIL: Could not open file > "pg_clog/001B": No such file or directory. > 2009-10-16 16:07:06 BRT 192.168.0.87 STATEMENT: select ... > 2009-10-16 16:11:47 BRT 192.168.0.29 ERROR: invalid page header in > block 462821 of relation "..." > 2009-10-16 16:11:47 BRT 192.168.0.29 STATEMENT: select .... > I created the file pg_clog/001B with 256kB of /dev/zero > That resolve the problem with vacuum but began other error in selects > and dump to the same table ended all connections and stay up after > showing the error: > 2009-10-19 13:50:03 BRT LOG: server process (PID 1544) was > terminated by signal 11 > 2009-10-19 13:50:03 BRT LOG: terminating any other active server > processes > 2009-10-19 13:50:03 BRT 192.168.0.253 WARNING: terminating connection > because of crash of another server process > 2009-10-19 13:50:03 BRT 192.168.0.253 DETAIL: The postmaster has > commanded this server process to roll back the current transaction and > exit, because another server process exited abnormally and possibly > corrupted shared memory. > 2009-10-19 13:50:03 BRT 192.168.0.253 HINT: In a moment you should be > able to reconnect to the database and repeat your command. > Was habilited the zero_damage_pages option then executed selects, > vacuums, and dumps but not changed... > Was identified 2 register that if refered cause error. > The BD was restored in backup server with 8.2.7 and executed vacuums > ok but select and reindex crashed... > > Instaled 8.3.8 version and used pg_dump but error > And then the select below show the problem where the codentrega from > where clause differ from select answer: > > LOGIST=# select codentrega from entregas where codentrega='9879622'; > codentrega > ------------ > z879622 > (1 registro) > > Any idea? -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander
pgsql-hackers by date: