Em 31 de julho de 2012 11:18, Flavio Henrique Araque Gurgel <[email protected]> escreveu: > > Em 31-07-2012 08:59, Tiago Adami escreveu: >> 2012/7/31 Fabio<[email protected]>: >> O seu problema está na tabela "pg_toast_78248" e não necessáriamente >> na tabela com os dados. Então: > > Opa opa > pg_toast_* tem dados sim. > As tabelas toast guardam dados acima de um certo tamanho, 8 kiB por padrão.
Correto. Quis dizer é que não é na "tabela principal", do esquema do usuário/aplicativo, ou seja, "documento_elaborado". Me expressei mal. >> 1) Carregue o banco de dados em modo "standalone" - sem ser pelo >> serviço e sim pelo console com o executável "postgres". Lembre de >> modificar o parâmetro "listen_adress=localhost" no seu >> "postgresql.conf"; >> 2) Execute o reindexdb com a opção "-s" (apenas catálogo do sistema) >> 3) Se ocorrer algum erro, poste aqui. Se o comando for realizado com >> sucesso, tente realizar o dump novamente. > > Sinto muito mas isso não vai resolver. > Quando existe erro "invalid page header..." houve corrupção dos dados em > disco. Exato, isso significa que "se" conseguir recuperar os dados alguma coisa irá faltar. > Não há o que fazer, houve perda de dados. (...) corte Respondi com certa pressa que esqueci de mencionar o parâmetro "zero_damaged_pages" [1]. Ele irá ignorar os blocos defeituosos e permanentemente marcá-los como inexistentes. Ou seja: *destruir todas as linhas que estão na página*. Carregando o banco em modo "standalone" e reindexando o catálogo eu já consegui zerar os blocos inválidos e realizar um pg_dump recuperando dados parcialmente. Pensando melhor, talvez o "reindexdb -s" não ajude muito nestes casos porque o problema foi em uma tabela, e não em um índice... mas até hoje é o procedimento que realizo neste tipo de situação e obtenho sucesso na maioria das vezes. NOTA: É importantíssimo lembrar que, antes de tentar estas dicas que passei, faça um backup real (não pelo pg_dump) dos arquivos do seu cluster com o serviço do SGBD desativado (toda a pasta *data*). Usando o "zero_damaged_pages" o resultado pode ser catastrófico e não há como desfazer suas alterações. [1] http://www.postgresql.org/docs/8.3/static/runtime-config-developer.html -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
