----- Original Message ----- From: "Flavio Henrique Araque Gurgel" <[email protected]> To: <[email protected]> Sent: Thursday, November 22, 2012 12:58 PM Subject: Re: [pgbr-geral] Invalid Memory Alloc Request Size
Em 20-11-2012 13:33, Joao Paulo Rieg escreveu: (...) > 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? Não. Eu me enganei, desculpe. > 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. O Jota já respondeu, sim, pode instalar em cima da atual. Tenha um backup dos arquivos de dados antes, claro. (...) >> 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. Me parece que você tem arquivo de tabela corrompido. O melhor jeito de resolver isso é restaurar um backup (se você tiver, espero que tenha). Caso não tenha, você tem algumas alternativas: 1a- exportar os dados da tabela para um arquivo texto usando SELECT e filtrando a(s) tupla(s) defeituosas, que você terá de descobrir. 1b- recriar a tabela e restaurar os dados. 2- conectar-se ao PostgreSQL em modo monousuário e tentar eliminar as páginas defeituosas da(s) tabela(s) envolvida(s). Não tenho fácil aqui agora nenhuma documentação sobre como fazer isso, mas existe, se puder dar uma pesquisada ou alguém na lista te ajudar. (...) > 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) Como eu disse, as transações preparadas sobrevivem reinício do servidor. Como você não tem nenhuma, ok. > 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 Sim, tente, sem problemas. Pergunta extra: este seu banco de dados por acaso foi atualizado de versão anterior do PostgreSQL usando pg_upgrade? []s __________________________________ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos & Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: [email protected] ______________________________ FREE SOFTWARE SOLUTIONS Muito obrigado Flávio Pelas dicas. >>Me parece que você tem arquivo de tabela corrompido. >>O melhor jeito de resolver isso é restaurar um backup (se você tiver, >>espero que tenha). >>Caso não tenha, você tem algumas alternativas: >>1a- exportar os dados da tabela para um arquivo texto usando SELECT e >>filtrando a(s) tupla(s) defeituosas, que você terá de descobrir. >>1b- recriar a tabela e restaurar os dados. Resolvemos o problema criando outra tabela identica, e fomos incluindo os registros que estavam na original, exceto as tuplas defeituosas. Depois truncamos a tabela de origem, e colocamos de volta os registros recuperados de volta. O backup e todas as funções de manutenção tornaram a funcionar normalmente. Estamos fazendo também um levantamento da situação do hardware, pois desconfiamos que há falhas no HD. Até então Obrigado! _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
