Em ter, 7 de fev de 2017 às 16:00, Fabiano Machado Dias < [email protected]> escreveu:
> Você não está gravando uma nota por cima de outra? Como seu "log" aponta a > gravação, pode ser que em algum determinado momento você esteja pegando > algum dado sujo e sobrescrevendo a nota que já tinha sido emitida, por isso > seu "log" não acusa erro. > > Já vi algo parecido acontecer com chaves seriais controladas pela camada > de persistência e tb por "sujeira" em variáveis de controle. > > De qualquer forma, faça como já foi recomendado, ligue os logs do banco e > confie neles, se o seu "log" não está apontando o erro é pq ele tb não é > confiável. > Tá cada vez mais duro responder à esta thread de top posts, mas enfim. O OP não respondeu a versão exata que ele está usando, mas não importa muito. Tem um bug descoberto recentemente no PostgreSQL que pode causar perda de dados em quem cria índices concorrentes à UPDATEs, o CREATE INDEX CONCURRENTLY. Esse bug afeta todas as versões atualmente suportadas e o patch que sair vai sair pra todas elas, lembrando que a 9.1 *não será corrigida* porque não é mais suportada. Então, pergunto ao OP se ele faz essa operação em algum lugar, seja dentro da aplicação, ou um trabalho agendado? A solução será simples, reindexar a coluna, se for o caso, sem usar CONCURRENTLY. Se outros UPDATEs não foram feitos na tabela, as chances são grandes dos dados reaparecerem, mas nada é garantido. []s Flavio Gurgel
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
