Oi, 2011/8/26 JotaComm <[email protected]>: > Olá, Diogo > > > Na verdade porque falo isso. > > Uma vez eu estava tentando configurar um PostgreSQL em um servidor e me > acontecia que quando eu alterava o valor do shared_buffer para um certo > tamanho (dentro do limite e do bom senso), eu recebia um erro de memória > corrompida, se colocava um valor mais baixo do que eu estava tentando > colocar o banco subia sem problemas, depois de alguns testes descobri que > uma parte da memória física do servidor estava corrompida. > > Você chegou a modificar o shared_buffers da instância da versão 9.0.4 do PG?
Sim, alterei o valor para 128MB. > > Se sim, tenta deixar o valor default e iniciar o serviço e veja se o > problema persiste? > Deixei, mas persistiu o problema, chegou a funcionar por alguns minutos. Estou começando a ter certeza do problema de memória. Mas ainda estou um tanto quanto surpreso de a versão anterior (PG 8.2.5) ainda funcionar e sem erros. Segue erro: LOG: server process (PID 3020) was terminated by signal 11: Segmentation fault LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. LOG: all server processes terminated; reinitializing LOG: database system was interrupted; last known up at 2011-08-26 10:16:29 BRT LOG: database system was not properly shut down; automatic recovery in progress LOG: consistent recovery state reached at 23/F5A738F0 LOG: redo starts at 23/F5A738F0 LOG: record with zero length at 23/F5B512E8 LOG: redo done at 23/F5B512A8 LOG: last completed transaction was at log time 2011-08-26 10:16:41.596779-03 LOG: autovacuum launcher started LOG: database system is ready to accept connections > Hoje eu tenho o mesmo ambiente que você, a única diferença que o meu > ambiente é RH 5.6, em vez da 5.5 que você tem, e tenho também o PG 9.0.4 e > até agora não tive nenhum problema, ainda bem :) > >> >> >> []s >> >> > Em 26 de agosto de 2011 09:09, Diogo Borsoi <[email protected]> >> > escreveu: >> >> >> >> Oi Euler, >> >> >> >> >> >> 2011/8/25 Euler Taveira de Oliveira <[email protected]>: >> >> > Em 25-08-2011 21:11, Diogo Borsoi escreveu: >> >> >> Obrigado pela dica, em parte funcionou, não está dando mais o erro >> >> >> de >> >> >> permissão. No entanto está acontecendo alguma coisa estranha, a >> >> >> aplicação "morre" ao executar alguma operação no BD, segue erro: >> >> >> >> >> > Qual é essa operação? Veja se o log não a informa antes da queda. >> >> > >> >> > Dê mais detalhes tais como SO e se migração foi com >> >> > pg_dump/pg_restore >> >> > ou >> >> > pg_upgrade. >> >> > >> >> >> >> 1. O SO é um Red Hat Enterprise Linux Server release 5.5 >> >> 2. Instalei via código fonte o PG 9.0.4 e migrei as bases do PG 8.2.5 >> >> através do comando: >> >> pg_dump -p 5432 -U postgres -d "nome_do_bd" -Fc -b -v | pg_restore >> >> -p >> >> 5433 >> >> -U postgres -v -d "nome_do_bd" >> >> >> >> > Isto está me parecendo um bug do PostgreSQL, mas preciso de mais >> >> > evidências >> >> > para classificá-lo como tal (principalmente se você puder montar uma >> >> > sequência >> >> > de comandos que ocasionam essa queda do servidor PostgreSQL). Se não >> >> > conseguir >> >> > a sequência de comandos, um _stack trace_ [1][2] já ajudaria. >> >> > >> >> > [1] >> >> > >> >> > >> >> > http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD >> >> > [2] >> >> > >> >> > >> >> > http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows >> >> > >> >> >> >> Infelizmente não consegui a sequência. E para executar o "stack trace" >> >> (gdb) eu preciso recompilar o PostgreSQL com as opções "--enable-debug >> >> && CFLAGS=-O0"? >> >> Eu não entendi muita bem a execução deste procedimento poderia, por >> >> favor, me exemplificar? >> > >> > Me ocorreu um fato. Já tive problemas parecidos e o problema era memória >> > do >> > servidor que estava corrompida. Você chegou a fazer u memtest? É >> > possível de >> > ser feito? >> > >> > >> >> >> >> []s >> >> >> >> > >> >> > -- >> >> > Euler Taveira de Oliveira - Timbira >> >> > http://www.timbira.com.br/ >> >> > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e >> >> > Treinamento >> >> > _______________________________________________ >> >> > pgbr-geral mailing list >> >> > [email protected] >> >> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > >> >> _______________________________________________ >> >> pgbr-geral mailing list >> >> [email protected] >> >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > >> > >> > Abraços >> > >> > -- >> > JotaComm >> > http://jotacomm.wordpress.com >> > >> > _______________________________________________ >> > pgbr-geral mailing list >> > [email protected] >> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > >> > >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > Abraços > > -- > JotaComm > http://jotacomm.wordpress.com > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
