Em 22 de julho de 2010 15:38, Euler Taveira de Oliveira <[email protected]> escreveu: > Tiago Adami escreveu: > > Você não nos disse qual o erro e nem mesmo qual é a versão (8.3.x?) que está > utilizando. Inúmeros bugs foram corrigidos nesta área. Você deve utilizar > sempre a última versão da série 8.3 (no momento 8.3.11). >
Eu citei o problema. Especificamente, os erros que aconteceram ou ainda acontecem em alguns casos são: 2010-07-18 13:44:41 BRT LOG: could not open file "pg_xlog/000000010000000500000073" (log file 5, segment 115): No such file or directory 2010-07-18 13:44:42 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2010-07-18 13:44:42 BRT FATAL: the database system is starting up 2010-07-18 13:44:43 BRT LOG: startup process (PID 548) was terminated by exception 0xC000000D 2010-07-18 13:44:43 BRT HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. 2010-07-18 13:44:43 BRT LOG: aborting startup due to startup process failure _SOLUÇÃO_: executar 'pg_resetxlog -f data'. Após passou a carregar o serviço. Com o banco carregado, ao tentar inserir dados na tabela LOG_CADASTRO que possui um campo do tipo LO (large object), passou a apresentar o erro *SQLSTATE=S1010 - Function Sequence Error* (na aplicação, isto não ficou registrado nos logs). Tentei então reindexar o catálogo com o comando 'reindexdb -s' , e outra mensagem de erro foi exibida: (corte) NOTICE: table "pg_amproc" was reindexed NOTICE: table "pg_language" was reindexed reindexdb: reindexação dos catálogos do sistema falhou: ERROR: could not access status of transaction 22266365 DETAIL: Could not read from file "pg_subtrans/0153" at offset 196608: No error. _SOLUÇÃO_: Já que o banco estava carregado, fiz um backup com o *pg_dump*, apaguei o banco antigo, criei um novo e restaurei o arquivo de backup. São estes procedimentos acima que quero tentar evitar. >> >> # - Checkpoints - >> >> checkpoint_segments = 1 >> checkpoint_timeout = 30s >> > Reduzindo os valores de checkpoint só irá aumentar a I/O na máquina. > >> Resumindo: deixei apenas um segmento para o checkpoint e reduzi ao >> máximo possível o tempo em que o WAL é escrito para tentar evitar que >> alguma coisa fique pendente. A idéia é fazer os dados sejam efetivados >> após o COMMIT o mais rápido possível. >> > A escrita dos dados em disco já está garantida pelo parâmetro fsync. Além > disso, o WAL é escrito *no momento* do COMMIT. O que o checkpoint faz é > escrever o que vai para o WAL (e está na memória) nos arquivos de dados (aka > datafiles). A escrita dos dados em disco não pode ser garantida com o fsync principalmente em Windows, caso contrário não haveriam os problemas descritos acima. E o que acontece se por algum motivo a máquina for desligada como por exemplo em uma falta abrupta de energia, quando os datafiles ainda não foram atualizados e acontece algum problema nos arquivos do WAL (ou seja, não consegue concluir o *REDO*)? > > Aposto R$ 0,02 que o seu problema está na utilização de versões antigas do > PostgreSQL e/ou de um sistema de arquivos não-confiável. > Não vou apostar contigo, neste ponto você tem razão. Nos dois, inclusive. Ontem mesmo solicitei a atualização para a 8.3.11, e o sistema de arquivos é NTFS. Bingo. Por fim, quer dizer então que estas modificações não vão surtir efeito em nada, exceto desempenho? -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
