Em 20-11-2012 08:45, Joao Paulo Rieg escreveu: > OK Flávio... > Desculpe pelo Top Post....
Tudo bem. Sempre pedimos isso, alguns entendem, outros não. Como dica, da próxima vez, responda também quotando a mensagem original (como estou fazendo aqui) que facilita MUIIIIITO. > A versão completa do PostgreSQL é: PostgreSQL 9.0.7, compiled by Visual > C++ > build 1500, 64-bit > A Arquitetura do servidor é: Dell PowerEdge T410, Processador Xeon E5620, > 2.4GHz, 16GB de memória, 4 HDs SAS 320GB sendo: 1 Array de RAID 1 para o > SO, > e outro Array de RAID 1 para o Cluster. O Array do Cluster está com 50% de > utilização. Você tem um bom servidor, bons discos até, pergunto: Você está usando Windows 32 bit? Não vi resposta ainda sobre isso. Qual a versão exata do Windows? --->Windows 2008 Server RC2 x64 bits Você tem uma máquina 64 bit e está usando PostgreSQL 32 bit. Recomendo usar PostgreSQL 64 bit também, desde que seu S.O. também seja. ---> O banco instalado é x64... Qual o valor do seu shared_buffers? ---> Estava com 2 GB, começou esse erro ai aumentamos para o 4GB onde o problema parou de acontecer por algumas semanas tornando a ocorrer novamente. Qual o valor de work_mem? ---> 15MB Se qualquer um deles for > 2 GiB você vai enfrentar o problema que está passando. ---> Mesmo se o SO e o Banco instalado for 64 bit? Atualize o PostgreSQL para 9.0.10 que é a versão corretiva mais recente pra eliminar bugs conhecidos. ---> Posso instalar ela por cima da atual? Pois com este problema não consigo fazer o dump da base. Performance (nada a ver com seu problema): separe um disco para o pg_xlog também, além do cluster. ---> Faremos isto. > Não utilizo o PostGis. Ok, então descarta o problema do link que citei. ---> Beleza... Eu estive olhando também. > Quanto aos índices, Eles foram criados de acordo com a necessidade das > consultas, porém no estado em que a tabela se encontra, não consigo nem > recriá-los. Se tento fazer o dump já da erro... Você não precisa fazer dump para recriar os índices, apenas faça REINDEX. Todavia, se você não consegue rodar COPY (o comando usado pelo pg_dump em backup comum) então REINDEX, talvez, não funcione. Como o erro é em COPY, o problema não são índices. ---> Exato... o comando: reindex ind_03_03_02_02_a3 se executado faz o banco dar um shutdown na hora. Da mesma forma que se eu executar um vacuum ind_03_03_02_02_a3. > os parâmetros: > autovacuum_cost_delay = 20ms > vacuum_cost_delay = 0 Default. Desencana pro seu erro. > postei os dois parâmetros por garantia pois percebi que você colocou os > dois > prefixos la em cima... De sua mensagem anterior (já que você não quotou, esqueceu): > Esqueci de avisar antes mas quando fui executar o vacuum pelo pgAdmin, > dava a mensagem que tem delete e insert concorrente, só que o banco > estava totalmente ocioso e não havia nenhuma conexao concorrente. > Achei muito estranho essas mensagens. Qual o resultado da consulta abaixo? SELECT * FROM pg_prepared_xacts; Pode haver um lock deixado por um 2PC. Locks assim resistem até restart do PostgreSQL. ---> nem uma linha retornada pela consulta. Até porque após este problema o banco reiniciou já. (Tentei fazer um vacuum e o banco parou) O único passo que eu não fiz foi atualizar para a versão 9.0.10. Preciso saber se acaso o cluster é compativel com essa nova versão do banco pois não consigo fazer o dump? atual: 9.0.7 para o 9.0.10 _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
