Preciso de ajuda para encontrar uma versão ou configuração do PostgreSQL que *evite* ao máximo corromper o banco de dados ao gravar dados em colunas do tipo BYTEA e LO (Long Object) e que mantenha ao máximo o WAL intacto (sem a necessidade de um "pg_resetxlog"). Eu já grifei a palavra *evite* pois sei que no Windows é impossível manter a integridade de qualquer banco de dados, ainda mais no cenário em que está sendo utilizado.
O cenário mais comum é o seguinte: 1) Software de POS (também chamado de *Frente de Caixa*) para supermercados; 2) PostgreSQL 8.3 em Windows XP (em andamento projeto para migrar para a versão 9.0). Mais de 500 instâncias atualmente rodando; 3) Aplicação grava informações compactadas em formato binário em pelo menos 5 tabelas do banco de dados (4 BYTEA e 1 LO). Estas informações são de um aplicativo de terceiros e não há como alterá-lo; 4) O banco de dados *incha* com muita rapidez. Em um mês atinge cerca de 6GB nos caixas, e as operações começam a se tornar lentas. Descobrimos que é por causa dos BLOBs, pois os dados binários são armazenados e frequentemente eliminados pelo aplicativo de comunicação de terceiros que é utilizado. *VACUUM* não resolve nada, *VACUUMLO* sim, mas com o efeito colateral de ficar muitas horas rodando deixando o caixa parado; 5) A tabela com ID 1663 (pg_largeobject) corrompe com muita facilidade e com muita frequencia; 6) *SEMPRE* é necessário rodar um "pg_resetxlog" quando cai a energia e um caixa é desligado. Acreditem, isto acontece muito em supermercados; 7) Existe um banco de dados concentrador de informações dos caixas também em PostgreSQL 8.3 com a mesma estrutura, mas rodando em Windows Server com hardwares nada modestos, e todos os problemas dos caixas estendem-se a ele; Temos certeza de que a grande maioria dos nossos problemas está no aplicativo de terceiros que faz com que os dados de réplica sejam gravados no banco de dados em formato binário. Sim, sabemos. E já estamos migrando desta ferramenta. O fato é que preciso resolver os problemas acima para dar um fôlego enquanto isto não acontece. E então. Alguém se arrisca em dizer se há alguma configuração do postgresql.conf que reduza a incidência destes erros? Contenham-se em dizer para migrar para Linux. Eu bem gostaria, mas não existe esta possibilidade - infelizmente. -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
