Ok Flavio,
Agradeco a resposta, vou levantar uma maquina nova para fazer isso e
retorno com resposta na sequencia.
Porem, fica uma duvida:
Como que depois desse problema, a tabela do Banco responsável pelos
dados que deram problema na pesquisa, estão OK hoje...? tipo, foi um erro
num determinado minuto do dia (não foi necessário fazer nada e os dados
voltaram ao normal).
-----Mensagem original-----
De: pgbr-geral [mailto:[email protected]] Em nome
de Flavio Henrique Araque Gurgel
Enviada em: terça-feira, 13 de janeiro de 2015 06:33
Para: [email protected]
Assunto: Re: [pgbr-geral] Error: could not read block 1 in file
"base/623739/277712901": read only 0 of 8192 bytes
> Boa Tarde Pessoal,
>
> Recentemente aconteceu o erro " Error: could not read
> block 1 in file "base/623739/277712901": read only 0 of 8192 bytes em
> um dos nossos servidores.
>
> Teoricamente, esse erro provocou um problema
> catastrófico (um sincronização de banco onde a aplicação entendeu que
> deveria fazer Delete de clientes e o fez).
>
> A questão é que não sei como simular esse
> comportamento, para realmente ter certeza que a aplicação não esta
> preparada para tratar essa resposta.
Pelo que entendi você teve uma perda de arquivo de dados ou corrupção.
> Obs: o Servidor que aconteceu o erro recebe varias
> leituras e escritas de outras maquinas... uma outra maquina X, vai
> até esse banco, faz um select bem pesadinho (uns 30 segs para
> executar) e o resultado desse select, um executável em TCL pega a
> resposta, compara a linha do select na base que deu problema com a
> linha do select de sua maquina local, dependendo do IF, faz UPDATE, INSERT
OU DELETE.
>
> Algum colega da lista saberia me dizer se existe a
> possibilidade de simular esse comportamento (fazer algo no disco, ou
> sei la o que... que no momento do select ele daria essa resposta). A
> ideia seria dar um start no executável com o bloco zuado e ver se
> realmente é ele que não sabe tratar esse problema de bloco e faz coisa
errada.
>
> Resumindo, como faço isso no bloco do disco
> Postgresql
> (intencionalmente) para simular a aplicação rodando em cima desse
> disco zuado.
Você pode simular uma falha como essa facilmente.
1) Escolha uma tabela conveniente, que será usada pelo seu SELECT. Vamos
usar de exemplo uma tabela chamada "tatabela" que está no banco "babanco"
2) Ache o nome do subdiretório correspondente ao seu banco de dados:
SELECT oid FROM pg_database WHERE datname = 'babanco';
3) Ache o nome do arquivo que corresponde à tabela:
SELECT refilenode FROM pg_class WHERE relname = 'tatabela';
4) Pare o PostgreSQL.
5) Vá no diretório do cluster, subdiretório base e mais o subdiretório que
corresponde ao oid do banco que você achou no item 2 acima.
6) Zere o arquivo da tabela que você acho no item 3 acima, supondo que o
relfilenode encontrado seja 12001:
touch 12001
7) Inicie o PostgreSQL e faça um SELECT sobre a tabela. Provavelmente você
verá o mesmo erro que encontrou antes.
Lembre-se que isto irá *destruir* o conteúdo da tabela. Tenha seu backup
antes e recrie completamente o cluster após isso.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
