Em 6 de setembro de 2013 21:31, Fabrízio de Royes Mello
fabri...@timbira.com.br escreveu:
On 06-09-2013 11:18, Euler Taveira wrote:
On 06-09-2013 11:13, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/6 Euler Taveira eu...@timbira.com.br:
…seria mais fácil se o Postgres mudasse a
Opa,
Em 5 de setembro de 2013 17:31, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 05-09-2013 17:24, JotaComm escreveu:
Ora ora...
Já que está usando CentOS, dá uma olhada em /var/log/messages
Digamos que CentOS não foi minha escolha, tive q aceita-lo.
Opa,
Em 5 de setembro de 2013 21:10, Euler Taveira eu...@timbira.com.brescreveu:
On 05-09-2013 16:51, JotaComm wrote:
Se eu te contar que este mesmo sintoma aconteceu na semana retrasada,
mandei um pg_ctl stop -mf, e mesmo assim o banco não parou, ele ficou
esperando um sinal do processo
2013/9/6 JotaComm jota.c...@gmail.com:
Eu sei que não, mas é que eu prefiro o Debian em relação ao Cent OS.
A base de dados do céu será um PostgreRelational reescrito em Lisp
sobre Debian GNU Hurd ou uma máquina Lisp… quer dizer, se os anjos
conseguirem terminar o Hurd ou ressuscitarem as
Pra bom entendedor, meio ;-) basta. hahahah
Em 6 de setembro de 2013 09:42, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2013/9/6 JotaComm jota.c...@gmail.com:
Eu sei que não, mas é que eu prefiro o Debian em relação ao Cent OS.
A base de dados do céu será um
2013/9/6 JotaComm jota.c...@gmail.com
Opa,
Em 5 de setembro de 2013 21:10, Euler Taveira eu...@timbira.com.brescreveu:
On 05-09-2013 16:51, JotaComm wrote:
Se eu te contar que este mesmo sintoma aconteceu na semana retrasada,
mandei um pg_ctl stop -mf, e mesmo assim o banco não parou,
2013/9/6 Euler Taveira eu...@timbira.com.br:
On 06-09-2013 11:13, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/6 Euler Taveira eu...@timbira.com.br:
…seria mais fácil se o Postgres mudasse a numeração
para 9.0 patch level 13 para ficar mais claro que os novos binários
são somente
2013/9/6 Euler Taveira eu...@timbira.com.br
On 06-09-2013 09:50, Matheus de Oliveira wrote:
As releases do PostgreSQL (o último
número na versão) não injeta nenhuma incompatibilidade, são basicamente
para pequenas melhorias e correções de bug
^
O Postgres não faz
On 06-09-2013 09:50, Matheus de Oliveira wrote:
As releases do PostgreSQL (o último
número na versão) não injeta nenhuma incompatibilidade, são basicamente
para pequenas melhorias e correções de bug
^
O Postgres não faz melhorias (aka funcionalidades) em versões
2013/9/6 Euler Taveira eu...@timbira.com.br
On 06-09-2013 11:13, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/6 Euler Taveira eu...@timbira.com.br:
…seria mais fácil se o Postgres mudasse a numeração
para 9.0 patch level 13 para ficar mais claro que os novos binários
são somente
On 06-09-2013 11:13, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/6 Euler Taveira eu...@timbira.com.br:
…seria mais fácil se o Postgres mudasse a numeração
para 9.0 patch level 13 para ficar mais claro que os novos binários
são somente *correções*.
Verdade, mas seria feio p’ra
2013/9/6 Leonardo Cezar lhce...@gmail.com:
Também desisti de explicar e comecei a recomendar[1]
[1] http://www.semver.org
Gostei, obrigado!
Aliás, já fugindo do tópico mas relevante para o bom funcionamento da
lista… porque colocar num rodapé o que caberia perfeitamente no texto?
Imagino que
2013/9/6 Euler Taveira eu...@timbira.com.br:
…seria mais fácil se o Postgres mudasse a numeração
para 9.0 patch level 13 para ficar mais claro que os novos binários
são somente *correções*.
Verdade, mas seria feio p’ra dedéu.
___
pgbr-geral mailing
2013/9/6 JotaComm jota.c...@gmail.com
Em 5 de setembro de 2013 21:10, Euler Taveira eu...@timbira.com.brescreveu:
On 05-09-2013 16:51, JotaComm wrote:
Se eu te contar que este mesmo sintoma aconteceu na semana retrasada,
mandei um pg_ctl stop -mf, e mesmo assim o banco não parou, ele
gl2013/9/6 Leonardo Cezar lhce...@gmail.com:
2013/9/6 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
2013/9/6 Leonardo Cezar lhce...@gmail.com:
Também desisti de explicar e comecei a recomendar[1]
[1] http://www.semver.org
Aliás, já fugindo do tópico mas relevante para o bom
2013/9/6 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
2013/9/6 Leonardo Cezar lhce...@gmail.com:
Também desisti de explicar e comecei a recomendar[1]
[1] http://www.semver.org
Gostei, obrigado!
Por nada.
Aliás, já fugindo do tópico mas relevante para o bom funcionamento da
On 06-09-2013 11:10, Euler Taveira wrote:
On 06-09-2013 09:50, Matheus de Oliveira wrote:
As releases do PostgreSQL (o último
número na versão) não injeta nenhuma incompatibilidade, são basicamente
para pequenas melhorias e correções de bug
^
O Postgres não faz
On 06-09-2013 11:18, Euler Taveira wrote:
On 06-09-2013 11:13, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/6 Euler Taveira eu...@timbira.com.br:
…seria mais fácil se o Postgres mudasse a numeração
para 9.0 patch level 13 para ficar mais claro que os novos binários
são somente
2013/9/4 JotaComm jota.c...@gmail.com
Pessoal,
Boa tarde!!!
Opa. Bom dia, =D...
Vou expor o meu problema e gostaria de saber se alguém já passou por
situação semelhante:
Tenho um vacuum rodando em uma tabela desde o dia 2013-08-27 18:58:
41.527238-03, no entanto a tabela não é
Bom dia!!!
Em 5 de setembro de 2013 09:07, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2013/9/4 JotaComm jota.c...@gmail.com
Pessoal,
Boa tarde!!!
Opa. Bom dia, =D...
Vou expor o meu problema e gostaria de saber se alguém já passou por
situação semelhante:
Tenho um
Bom dia!!!
Em 4 de setembro de 2013 15:47, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 04-09-2013 14:55, JotaComm escreveu:
Pessoal,
Boa tarde!!!
Vou expor o meu problema e gostaria de saber se alguém já passou por
situação semelhante:
Tenho um vacuum rodando em
2013/9/5 JotaComm jota.c...@gmail.com:
Em 5 de setembro de 2013 09:07, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2013/9/4 JotaComm jota.c...@gmail.com
A versão do SO é CentOS release 6.3 (Final).
Também vale a pena atualizar para o 6.4 […]
Concordo, porém nem tudo é tão
On 05-09-2013 09:55, JotaComm wrote:
Exato, é um JOIN entre estas tabelas. O vacuum não está bloqueado (waiting
= FALSE) e em pg_locks granded=TRUE. Não tenho prepared statements
bloqueadas neste banco.
O mais estranho é que não consigo matar, conforme descrevi acima.
Isso parece-me bug
On 09/05/2013 09:57 AM, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/5 JotaComm jota.c...@gmail.com:
Em 5 de setembro de 2013 09:07, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2013/9/4 JotaComm jota.c...@gmail.com
A versão do SO é CentOS release 6.3 (Final).
Também vale
2013/9/4 JotaComm jota.c...@gmail.com:
Pessoal,
Boa tarde!!!
Vou expor o meu problema e gostaria de saber se alguém já passou por
situação semelhante:
Tenho um vacuum rodando em uma tabela desde o dia 2013-08-27
18:58:41.527238-03, no entanto a tabela não é grande: 5.428.982 - (8243 MB
On 09/05/2013 09:55 AM, JotaComm wrote:
Bom dia!!!
A versão do SO é CentOS release 6.3 (Final).
Também vale a pena atualizar para o 6.4, mas não vejo como algo tão
crítico/urgente.
Concordo, porém nem tudo é tão simples :(
eu acho muito simples, basta rodar
yum -y update, porem te
2013/9/5 Itamar Reis Peixoto ita...@ispbrasil.com.br:
se estiver utilizando os pacotes rpm que vem no centos, te recomendo a
reportar um bug no bugzilla do centos ou da propria Red Hat.
A Red Hat aceita relatos de defeitos nos pacotes do CentOS? Sei que
em princípio são os mesmos, mas fiquei
2013/9/5 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
Melhor para eles! Mas veja que o assunto não era Red Hat, só CentOS.
sim, mas o centos é uma recompilação dos fontes do red hat enterprise
linux, então o pacote do postgresql
que vem no centos é uma recompilação do que foi feito
2013/9/5 Itamar Reis Peixoto ita...@ispbrasil.com.br:
On 09/05/2013 09:57 AM, Guimarães Faria Corcete DUTRA, Leandro wrote:
Em 5 de setembro de 2013 09:07, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2013/9/4 JotaComm jota.c...@gmail.com
A versão do SO é CentOS release 6.3
2013/9/5 JotaComm jota.c...@gmail.com
Bom dia!!!
Em 5 de setembro de 2013 09:07, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2013/9/4 JotaComm jota.c...@gmail.com
Pessoal,
Boa tarde!!!
Opa. Bom dia, =D...
Vou expor o meu problema e gostaria de saber se alguém já
2013/9/5 Itamar Reis Peixoto ita...@ispbrasil.com.br
On 09/05/2013 09:57 AM, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/5 JotaComm jota.c...@gmail.com:
Em 5 de setembro de 2013 09:07, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2013/9/4 JotaComm jota.c...@gmail.com
2013/9/5 Itamar Reis Peixoto ita...@ispbrasil.com.br:
2013/9/5 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
Melhor para eles! Mas veja que o assunto não era Red Hat, só CentOS.
sim, mas o centos é uma recompilação dos fontes do red hat enterprise
linux, então o pacote do
eu gostaria de dizer que quem paga o salario do Tom Lane 'e a Red Hat e
que o pacote do postgresql que existe no centos foi feito pelo proprio.
pagava... agora é a SalesForce [1].
[1] http://www.databasejournal.com/news/postgresql-tom-lane-salesforce.html
Atenciosamente,
o ultimo
On 05-09-2013 10:29, Matheus de Oliveira wrote:
Logo depois disso é possível que o autovacuum seja disparado nessa tabela
novamente, se não terminar rápido de novo, tente desabilitar
temporariamente o autovacuum só para essa tabela e tente fazer o vacuum
na mão com verbose e ver se te dé
2013/9/5 Euler Taveira eu...@timbira.com.br
On 05-09-2013 10:29, Matheus de Oliveira wrote:
Logo depois disso é possível que o autovacuum seja disparado nessa tabela
novamente, se não terminar rápido de novo, tente desabilitar
temporariamente o autovacuum só para essa tabela e tente fazer
Em 05-09-2013 09:57, JotaComm escreveu:
Quanto tá o autovacuum_vacuum_cost_delay e
autovacuum_vacuum_cost_limit ?
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = -1
Como autovacuum_vacuum_cost_limit = -1, ele usa vacuum_cost_limit. Tá
quanto lá?
O
Opa,
Em 5 de setembro de 2013 12:15, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 05-09-2013 09:57, JotaComm escreveu:
Quanto tá o autovacuum_vacuum_cost_delay e
autovacuum_vacuum_cost_limit ?
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit
Euler,
Em 5 de setembro de 2013 10:05, Euler Taveira eu...@timbira.com.brescreveu:
On 05-09-2013 09:55, JotaComm wrote:
Exato, é um JOIN entre estas tabelas. O vacuum não está bloqueado
(waiting
= FALSE) e em pg_locks granded=TRUE. Não tenho prepared statements
bloqueadas neste banco.
2013/9/5 Flavio Henrique Araque Gurgel fla...@4linux.com.br:
Em 05-09-2013 15:55, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2013/9/5 Flavio Henrique Araque Gurgel fla...@4linux.com.br:
Não, ele não tem problema de kernel. Pode até ter um processo que não
escutou o sinal enviado, mas não
Em 05-09-2013 15:47, Itamar Reis Peixoto escreveu:
Isso foi o que tinha imaginado, o problema é que não consigo matar o
processo atual, nem via pg_cancel_backend, nem via kill -TERM ou kill
-SIGINT. Poderia até tentar um kill -9, mas é muito agressivo isso.
eu já teria feito isto a muito
Em 05-09-2013 15:55, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2013/9/5 Flavio Henrique Araque Gurgel fla...@4linux.com.br:
Não, ele não tem problema de kernel. Pode até ter um processo que não
escutou o sinal enviado, mas não problema no kernel.
Está aí algo que eu gostaria de
Em 05-09-2013 15:31, JotaComm escreveu:
Como autovacuum_vacuum_cost_limit = -1, ele usa vacuum_cost_limit.
Tá quanto lá?
postgres=# SHOW vacuum_cost_delay;
vacuum_cost_delay
---
0
(1 row)
Cara, fiz uma confusão aqui.
Acabei de olhar um post do Tom Lane (a orelha
On 05-09-2013 15:41, JotaComm wrote:
Segue o strace do processo:
semop(2162752, {{10, 1, 0}}, 1) = 0
semop(2162752, {{9, -1, 0}}, 1) = 0
[corte]
semop(2162752, {{9, -1, 0}}, 1) = 0
semop(2162752, {{9, -1, 0}}, 1) = 0
select(0, NULL, NULL, NULL, {0, 1000})
2013/9/5 Flavio Henrique Araque Gurgel fla...@4linux.com.br:
Não, ele não tem problema de kernel. Pode até ter um processo que não
escutou o sinal enviado, mas não problema no kernel.
Está aí algo que eu gostaria de entender melhor.
___
pgbr-geral
2013/9/5 JotaComm jota.c...@gmail.com:
Isso foi o que tinha imaginado, o problema é que não consigo matar o
processo atual, nem via pg_cancel_backend, nem via kill -TERM ou kill
-SIGINT. Poderia até tentar um kill -9, mas é muito agressivo isso.
eu já teria feito isto a muito tempo, se o kill
Em 05-09-2013 16:51, JotaComm escreveu:
Os dados estão em um Storage.
Parece-me que a única forma de resolver o problema será uma interrupção
brusca do serviço. :(
Se eu te contar que este mesmo sintoma aconteceu na semana retrasada,
mandei um pg_ctl stop -mf, e mesmo assim o banco
Em 5 de setembro de 2013 17:08, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 05-09-2013 16:51, JotaComm escreveu:
Os dados estão em um Storage.
Parece-me que a única forma de resolver o problema será uma
interrupção
brusca do serviço. :(
Se eu te contar que
Flávio,
Em 5 de setembro de 2013 15:47, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 05-09-2013 15:31, JotaComm escreveu:
Como autovacuum_vacuum_cost_limit = -1, ele usa vacuum_cost_limit.
Tá quanto lá?
postgres=# SHOW vacuum_cost_delay;
vacuum_cost_delay
Em 05-09-2013 17:24, JotaComm escreveu:
Ora ora...
Já que está usando CentOS, dá uma olhada em /var/log/messages
Digamos que CentOS não foi minha escolha, tive q aceita-lo.
Nossa, eu não tava falando mal dele não. Tenho dezenas de PostgreSQL em
CentOS sem problema algum.
Não
Euler,
Em 5 de setembro de 2013 15:54, Euler Taveira eu...@timbira.com.brescreveu:
On 05-09-2013 15:41, JotaComm wrote:
Segue o strace do processo:
semop(2162752, {{10, 1, 0}}, 1) = 0
semop(2162752, {{9, -1, 0}}, 1) = 0
[corte]
semop(2162752, {{9, -1, 0}}, 1)
On 05-09-2013 16:51, JotaComm wrote:
Se eu te contar que este mesmo sintoma aconteceu na semana retrasada,
mandei um pg_ctl stop -mf, e mesmo assim o banco não parou, ele ficou
esperando um sinal do processo do autovacuum. Para conseguir parar o banco,
tive usar a força bruta e fazer um reboot
On 05-09-2013 16:18, Guimarães Faria Corcete DUTRA, Leandro wrote:
2013/9/5 Flavio Henrique Araque Gurgel fla...@4linux.com.br:
Em 05-09-2013 15:55, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2013/9/5 Flavio Henrique Araque Gurgel fla...@4linux.com.br:
Não, ele não tem problema de
Pessoal,
Boa tarde!!!
Vou expor o meu problema e gostaria de saber se alguém já passou por
situação semelhante:
Tenho um vacuum rodando em uma tabela desde o dia 2013-08-27
18:58:41.527238-03, no entanto a tabela não é grande: 5.428.982 - (8243 MB
incluindo indices).
Estou achando muito
Em 04-09-2013 14:55, JotaComm escreveu:
Pessoal,
Boa tarde!!!
Vou expor o meu problema e gostaria de saber se alguém já passou por
situação semelhante:
Tenho um vacuum rodando em uma tabela desde o dia 2013-08-27
18:58:41.527238-03, no entanto a tabela não é grande: 5.428.982 - (8243
MB
Olá a todos , Estou com problemas durante o vacuum, ele esta muito demorado , tenho um banco de 14 GB deixo ele rodando as 3 da manhã no cron e ele não demorava tanto, mas ultimamente ele tem ficado rodando até as 7 da manhã.Ja aumentei o tamanho da memória no maintenance_work_mem para 512MB
Em 10-05-2011 08:30, Cristiano Alves escreveu:
Estou com problemas durante o vacuum, ele esta muito demorado , tenho um
banco de 14 GB deixo ele rodando as 3 da manhã no cron e ele não
demorava tanto, mas ultimamente ele tem ficado rodando até as 7 da
manhã.Ja aumentei o tamanho da memória no
Versão 8.2.11Att, Cristiano Paiva Alves TI- Tecnologia da Informação Irmandade da Santa Casa de Caridade de Alegrete Fone: (55) 3422 2888 Ramal: 274/302 Em 10/05/2011 às 08:50 horas, pgbr-geral@listas.postgresql.org.br escreveu:Em 10-05-2011 08:30, Cristiano Alves escreveu: Estou com
Em 10 de maio de 2011 08:53, Cristiano Alves
cristi...@santacasaalegrete.org.br escreveu:
Versão 8.2.11
Uma dica, essa sua versão está bem antiga, atualize pelo menos para última
8.2 que é a 8.2.21.
--
Fabrízio de Royes Mello
Blog sobre TI: http://fabriziomello.blogspot.com
Perfil
Opa,
Outra coisa. O Euler comentou muito bem do uso do Vacuum Full e além disso
ele bloqueia a tabela no qual ele esta trabalho, sendo assim seu sistema
pode ficar travado durante este problema, logo não é muito aconselhável.
Em 10 de maio de 2011 09:12, Fabrízio de Royes Mello
É o vacuum normal não bloqueia a tabela onde esta trabalhando? Ou seja não tranca durante o seu uso?Att, Cristiano Paiva Alves TI- Tecnologia da Informação Irmandade da Santa Casa de Caridade de Alegrete Fone: (55) 3422 2888 Ramal: 274/302 Em 10/05/2011 às 09:32 horas,
Olá,
Em 10 de maio de 2011 09:39, Cristiano Alves
cristi...@santacasaalegrete.org.br escreveu:
É o vacuum normal não bloqueia a tabela onde esta trabalhando? Ou seja não
tranca durante o seu uso?
Exato. Vacuum normal não bloqueia nada.
Att,
Cristiano Paiva Alves
TI- Tecnologia da
Vlw pelas dicas.Att, Cristiano Paiva Alves TI- Tecnologia da Informação Irmandade da Santa Casa de Caridade de Alegrete Fone: (55) 3422 2888 Ramal: 274/302 Em 10/05/2011 às 10:03 horas, pgbr-geral@listas.postgresql.org.br escreveu:Olá,Em 10 de maio de 2011 09:39, Cristiano Alves
62 matches
Mail list logo
