On 12-03-2014 15:16, Fabio Barros wrote:
Pessoal, considerem um sistema antigo rodando em kernel 2.4 e postgres 7.2,
conforme info abaixo:
PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 2.96
Que nostalgia!
. . .
A atualização é urgente! A versão 7.2 possui sérios problemas
On 13-03-2014 09:24, Fabio Barros wrote:
Euler, eu havia rodado um psql --version, mas completando a informação,
segue consulta abaixo:
# rpm -qa | grep
postgrespostgresql-7.2-12mdkpostgresql-server-7.2-12mdkpostgresql-postinstall-2.0-2
Quanto a urgência, claro, não há nem discussão
argumentos, 'queimando cartucho' e
perdendo qualquer possibilidade de migração.
Alguma sugestão? Dica de abordagem? Como convencer que a atualização é
necessária (talvez urgente)?
Agradeço a possível ajuda.
[]´s
Fabio Barros
no tempo?!?!?! (desculpem a ignorância)
obs: não vou ter funções como a do meu exemplo, é apenas para tentar entender
alguns conceitos.
Grato,Fabio Barros
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
segundos
Particularmente, acho muito interessante este tipo de dúvida, e por isso
resolvi postar aqui
Pq toda essa diferença no tempo?!?!?! (desculpem a ignorância)
obs: não vou ter funções como a do meu exemplo, é apenas para tentar entender
alguns conceitos.
Grato,Fabio Barros
:01 -0200
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] HD lotou no meio de um reindex
2013/12/3 Fabio Barros fabi...@hotmail.com
Boa tarde!
Estou postando minha primeira dúvida na lista, e agradeço possíveis comentários.
Opa. Seja bem-vindo.
Fiz um REINDEX em uma
: matioli.math...@gmail.com
Date: Thu, 5 Dec 2013 09:20:23 -0200
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] HD lotou no meio de um reindex
2013/12/5 Fabio Barros fabi...@hotmail.com
Bom dia!!!
Pessoal, agradeço os comentários!!!
Vamos lá, pretendo não prolongar mais o assunto
fisicamente voltou para
os 9GB, mas temos o inconveniente de não poder fazer nada na base de dados
enquanto o processo é feito.
Posso simplesmente remover os arquivos 'perdidos'?
Há outro meio, mais seguro, de se fazer isso?
Desde já, agradeço as possíveis sugestões.
[]´s
Fabio Barros
falaram
aqui na empresa, a evolucao para outra versao é custosa, visto que envolve
kernel do linux e necessidade de recompilacao de todos os modulos da aplicacao
(que eh gigante, escrita em C/C++) e reteste de tudo.
Desde já, agradeço possiveis comentarios.
[]'s
Fabio Barros
pgbr-geral@listas.postgresql.org.br
Message-ID:
aanlkti=ednyxmhec3kawyp-8-qtsw-wfyzukbd5f3...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1
Olá,
Em 28 de julho de 2010 10:30, fabio barros fabi...@hotmail.com escreveu:
Bom dia pessoal!
Rodei um script .sh que tem
Temos uma aplicação que faz muitos acessos as tabelas, e ela tem um controle de
timeout para obtenção de conexao e tb para execucao de comandos.
O controle de timeout é de 3 segundos, e renovado por mais 3x, ou seja, se
depois de 12 segundos não conseguir a conexao ou a execucao do comando
Jota e Osvaldo, obrigado pelo retorno referente ao VACUUM.
Segue ações q tomamos e considerações:
. estamos trocando o VACUUM ANALYZE por VACUUM FULL ANALYSE
se antes o vacuum não marcava os registros para reaproveitamento, com o full
pulamos esta parte e já liberamos espaço do hd.
. por
processamento, o espaço foi
liberado. Tamanho original da base: 60 GB e após vacuum full: 45 GB.
Se alguém souber alguma coisa ou tiver uma sugestão de investigação eu agradeço!
Abraços!!
Fabio Barros
13 matches
Mail list logo
