[pgbr-geral] RES: RES: Matar Usuario Postgresql 8l.2
Esto com um problema no processo. 1 – Kill usuários. 2 – drop banco. 3 – create banco 4 – restore banco. Funcionando. Problema Algum usuário tentar conexão no processo. Usei o psql abaixo, trava a conexão. Só que ai eu também não consigo fazer o processo. Trava tudo mundo. Alguma ideia. De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Agape World Informática Ltda Enviada em: terça-feira, 25 de agosto de 2015 09:58 Para: 'Comunidade PostgreSQL Brasileira' Assunto: [pgbr-geral] RES: Matar Usuario Postgresql 8l.2 Muito Obriagdo. Funcionou. De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Matheus de Oliveira Enviada em: terça-feira, 25 de agosto de 2015 09:17 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Matar Usuario Postgresql 8l.2 2015-08-24 18:10 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Como faço para parar todos os usuarios do banco postgresql 8.2 Em 2015 e você usando a versão 8.2? Tem gente que gosta de sofrer mesmo... xP Não estou achando. Tenho que fazer o seguinte. - drop no banco. - create - restaurar o banco. Ah... Mais uma coisa que esqueci de mencionar e vou deixar aqui como referência. O que passamos aqui vai funcionar para a grande maioria dos casos, mas tem uma situação bem específica (e bem chata) onde um usuário pode conectar entre o kill e o DROP DATABASE. Mesmo renomeando a base isso pode acontecer em versões mais recentes por causa do autovacuum. Uma forma de se resolver isso é desabilitar a possibilidade de conexão na base fazendo um UPDATE na pg_database: UPDATE pg_database SET datallowconn = false WHERE datname = 'nome_da_base'; -- Fazer o `kill -TERM pid` DROP DATABASE nome_da_base; ... faz o CREATE e a restauração aqui ... Quanto à parte do kill manual na 8.2, você pode fazer via shell: $ psql -c UPDATE pg_database SET datallowconn = false WHERE datname = 'nome_da_base'; $ psql -AXtqc SELECT procpid FROM pg_stat_activity WHERE datname = 'nome_da_base'; | xargs kill -TERM ATENÇÃO: em geral não é recomendado fazer atualização em tabelas de catálogo, mas sabe-se que as colunas datallowcon e datistemplate da pg_database são seguras de atualizar, tanto que na versão 9.5 criou-se as opções ALLOW_CONNECTIONS e IS_TEMPLATE no comando ALTER DATABASE para fazer essa operação, assim, na 9.5, ficaria: ALTER DATABASE nome_da_base WITH ALLOW_CONNECTIONS=false; SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'nome_da_base'; DROP DATABASE nome_da_base; Atenciosamente, -- Matheus de Oliveira _ https://www.avast.com/antivirus Avast logo Este email foi escaneado pelo Avast antivírus. www.avast.com https://www.avast.com/antivirus --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Espelhamento !!
2015-08-25 10:46 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Infelizmente não tenho como fazer isso. Maquinas nas lojas Windows 7. Web servidor Linux. E não tem como mudar isso, esse é um dos meus grandes problemas. Ainda não sei como proceder para fazer isso funcionar. Nem quais ferramentas usar. Qual a versão do seu PostgreSQL? Se estiver usando a versão 9.4 ou puder fazer o upgrade, compensa testar o BDR (Bi-Directional Replication) [1]. No seu caso seria usar como UDR (Uni-Directional Replication) [2]. Outras opções seriam os projetos que implementam replicação baseado em triggers, como Slony, Bucardo, Londiste, etc. [1] http://2ndquadrant.com/en/resources/bdr/ [2] http://bdr-project.org/docs/stable/overview-udr.html https://wiki.postgresql.org/images/a/a8/Udr-pgconf.pdf Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [PGBR2015] Sugestões Temas para Fishbowl
On 18-08-2015 16:00, Fernando Ike wrote: On Tue, 2015-08-18 at 14:58 -0300, Fabrízio de Royes Mello wrote: Pessoal, Esse ano estamos com a idéia de promover um Fishbowl [1] dentro do evento, então precisamos de idéias sobre assuntos. Exemplo: - Comunidade PostgreSQL Brasil - Mercado de Trabalho PostgreSQL - Como ajudar o PostgreSQL a crescer - Quero ajudar/me envolver o que faço - DBA 2.0 ou 3.0? Poderia falar um pouco mais a respeito? Tem a ver com toda evolução que estamos sofrendo seja com Métodos Ágeis (nada novo), DevOps, Bigdata, NoSQL?? Seria isso? Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: RES: Espelhamento !!
2015-08-25 11:18 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Sim, posso mudar a base das lojas para 9.4 sem problema. Por favor, sempre atualize para uma versão suportada, preferencialmente a última, se possível antes de pedir ajuda. Isso facilita muito quem se propöe a te ajudar voluntariamente. E, aproveitando, siga a netiqueta, começando por ler a RFC 1855. Isso seria sinal de αγαπε para com os outros participantes. Já te pediram para evitar as respostas no topo: evite também as frases mal formadas, difíceis de entender; as mensagens formatadas (use texto simples); e os sinais de exclamação desnecessários. Se estiver difícil de configurar o Micro$oft Outlook para respeitar as convenções da lista, use um cliente livre como o Gnome Evolution, o Mozilla Thunderbird ou o K-9. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Matar Usuario Postgresql 8l.2
2015-08-25 11:17 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Algum usuário tentar conexão no processo. Usei o psql abaixo, trava a conexão. Só que ai eu também não consigo fazer o processo. Trava tudo mundo. O seu usuário (que está executando essas operações) deve usar outro banco de dados para conectar-se, você não pode usar a base que está querendo remover nas suas conexões. Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento do Slony
Roger, Amigos, Estou tentando realizar monitoramento dos logs no Slony, já vi na documentação que existem alguns plugins para o Nagios, porém nenhum deles funciona conforme documentado. Alguem saberia de uma ferramenta que pudesse realizar este monitoramento de tal forma que a partir de qualquer erro informado nos logs pudesse ser sinalizado para uma ação imediata ? Eu monitoro no meu cluster utilizando o check_postgres [1] do Bucardo, funciona muito bem, e é muito fácil de utilizar. [1] https://github.com/bucardo/check_postgres Rogério Cunha Carvalho Muitos são os planos no coração do homem, mas o que prevalece é o propósito do Senhor. Provérbios 19:21 There are many plans in a man's heart; nevertheless the counsel of the LORD, that shall stand. Proverbs 19:21 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *__**Renan Catalani Fuentes de Campos* *Linkedin: br.linkedin.com/in/renanfuentes/ http://br.linkedin.com/in/renanfuentes/* *Skype:** renan_fuentes* *Telefone: (19) 9 9717-9845* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: RES: RES: Espelhamento !!
Sim, posso mudar a base das lojas para 9.4 sem problema. E instalar uma nova versão na web a 9.4 tambem. De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Matheus de Oliveira Enviada em: terça-feira, 25 de agosto de 2015 10:56 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] RES: RES: Espelhamento !! 2015-08-25 10:46 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Infelizmente não tenho como fazer isso. Maquinas nas lojas Windows 7. Web servidor Linux. E não tem como mudar isso, esse é um dos meus grandes problemas. Ainda não sei como proceder para fazer isso funcionar. Nem quais ferramentas usar. Qual a versão do seu PostgreSQL? Se estiver usando a versão 9.4 ou puder fazer o upgrade, compensa testar o BDR (Bi-Directional Replication) [1]. No seu caso seria usar como UDR (Uni-Directional Replication) [2]. Outras opções seriam os projetos que implementam replicação baseado em triggers, como Slony, Bucardo, Londiste, etc. [1] http://2ndquadrant.com/en/resources/bdr/ [2] http://bdr-project.org/docs/stable/overview-udr.html https://wiki.postgresql.org/images/a/a8/Udr-pgconf.pdf Atenciosamente, -- Matheus de Oliveira --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível bug no PostgreSQL - Storage parameters inválidos do toast são aceitos no ALTER TABLE
Para te ajudar segue uma pequena PL para remover do catálogo um reloption de uma relação: Puxa, eu estava pensando em resolver o problema usando o ALTER TABLE RESET, mas pelo q vc disse no e-mail anterior não vai funcionar, então só via esse PL mesmo. Espero ter ajudado... Sim, foi muito importante a ajuda. Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Diferença condicional para campos boolean
Pessoal, Existe diferença entre os where abaixo? WHERE campo_boolean IS TRUE WHERE campo_boolean = TRUE []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: RES: Matar Usuario Postgresql 8l.2
Ok. Obrigado. Foi isso que fiz. -Mensagem original- De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Dickson S. Guedes Enviada em: segunda-feira, 24 de agosto de 2015 19:41 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] RES: Matar Usuario Postgresql 8l.2 Em 24 de agosto de 2015 19:00, Agape World Informática Ltda ag...@agapeworld.com.br escreveu: No 8.2 isso não funciona. select pg_terminate_backend Exatamente, esta função surgiu na 8.4. Num versão tão antiga quanto a sua você pode fazer utilizando o sistema operacional com o comando 'kill' nos PIDs, mas muito cuidado para *não* enviar o sinal errado (por exemplo -9 sem querer) e derrubar a instancia inteira. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença condicional para campos boolean
2015-08-25 15:13 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com: WHERE campo_boolean IS TRUE WHERE campo_boolean = TRUE IS e = tem diferença, mas na cláusula WHERE o efeito vai ser o mesmo. Explico: `campo_boolean = TRUE` pode retornar 3 valores: - TRUE (verdadeiro) caso campo_boolean seja TRUE - FALSE (falso) caso campo_boolean seja FALSE - NULL (nulo) caso campo_boolean seja NULL Enquanto `campo_boolean IS TRUE` pode retornar 2 valores somente: - TRUE (veradeiro) caso campo_boolean seja TRUE (igual ao = ) - FALSE (false) caso campo_boolean seja FALSE **ou** caso campo_boolean seja NULL Resumindo, ambos tratam o NULL de forma diferente, e IS nunca irá retornar NULL. Agora, o efeito vai ser o mesmo no WHERE porque quando retorna-se NULL numa expressão do WHERE é equivalente à ter retornado FALSE. Cuidado, isso não quer dizer que NULL seja equivalente à FALSE, isso depende do contexto, numa cláusula CHECK, por exemplo, retornar NULL é equivalente à TRUE, ou seja, o efeito é ignorar a verificação (ignorar a linha no WHERE, ignora a checagem do CHECK). Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível bug no PostgreSQL - Storage parameters inválidos do toast são aceitos no ALTER TABLE
On 25-08-2015 16:37, Everton Berz wrote: Oi identificamos no nosso ambiente uma tabela que possui no seu storage parameters a definição toast.autovacuum_analyze_scale_factor. Segundo a documentação [1], este parâmetro não é possível no toast, somente na tabela diretamente. Percebemos que o CREATE TABLE realmente não aceita definir esta propriedade toast.autovacuum_analyze_scale_factor, entretanto um ALTER TABLE ... SET permite defini-la. Acho que seu catálogo foi alterado equivocadamente, porque esse parâmetro não é permitido para TOAST tanto com CREATE TABLE quanto ALTER TABLE. Veja o exemplo na mesma versão que estás utilizando: fabrizio=# SELECT version(); version -- PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit (1 row) fabrizio=# CREATE TABLE foo(t TEXT); CREATE TABLE fabrizio=# ALTER TABLE foo SET (autovacuum_analyze_scale_factor=2); ALTER TABLE fabrizio=# ALTER TABLE foo SET (toast.autovacuum_analyze_scale_factor=2); ERROR: unrecognized parameter autovacuum_analyze_scale_factor fabrizio=# DROP TABLE foo; DROP TABLE fabrizio=# CREATE TABLE foo(t TEXT) WITH (autovacuum_analyze_scale_factor=2); CREATE TABLE fabrizio=# DROP TABLE foo; DROP TABLE fabrizio=# CREATE TABLE foo(t TEXT) WITH (toast.autovacuum_analyze_scale_factor=2); ERROR: unrecognized parameter autovacuum_analyze_scale_factor Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Possível bug no PostgreSQL - Storage parameters inválidos do toast são aceitos no ALTER TABLE
Oi identificamos no nosso ambiente uma tabela que possui no seu storage parameters a definição toast.autovacuum_analyze_scale_factor. Segundo a documentação [1], este parâmetro não é possível no toast, somente na tabela diretamente. Percebemos que o CREATE TABLE realmente não aceita definir esta propriedade toast.autovacuum_analyze_scale_factor, entretanto um ALTER TABLE ... SET permite defini-la. Tentei encontrar na pgsql-hackers ou em alguma lista de bugs mas não encontrei. O mais próximo que encontrei foi essa thread [2] que o Euler participa e comenta sobre as storage parameters do Toast, mas não sei se esse problema está envolvido. PostgreSQL versão 9.3.5 Red Hat 6.4 Kernel 2.6.32-358.18.1.el6.x86_64 [1] http://www.postgresql.org/docs/9.3/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS [2] http://www.postgresql.org/message-id/20090209205800.08507755...@cvs.postgresql.org -- Everton ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível bug no PostgreSQL - Storage parameters inválidos do toast são aceitos no ALTER TABLE
On 25-08-2015 18:26, Everton Berz wrote: Fabrízio acredito que só aconteça quando as outras propriedades (não toast) estejam setadas. Veja se consegue reproduzir os comandos abaixo. Entretanto percebi agora que quando fiz na tabela zerada, apesar de não emitir erro, o parâmetro não é setado efetivamente. Fica a dúvida de como na nossa tabela antiga aquele parâmetro foi injetado. Pode ter acontecido durante algum pg_upgrate ou algo do tipo. [root@xxx04-bug-db ~]# psql -U postgres everton_destino psql (9.3.5) Digite help para ajuda. everton_destino=# select version(); version -- PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit (1 registro) everton_destino=# CREATE TABLE tb_hash_session ( everton_destino(# id_hash_session integer NOT NULL, everton_destino(# id_pessoa integer NOT NULL, everton_destino(# ds_hash character varying(40) NOT NULL, everton_destino(# dt_expiracao timestamp without time zone NOT NULL, everton_destino(# ds_ip character varying(40) NOT NULL everton_destino(# ) everton_destino-# WITH ( everton_destino(# autovacuum_enabled=true, autovacuum_analyze_scale_factor=0.001, autovacuum_analyze_threshold=1, everton_destino(# autovacuum_vacuum_scale_factor=0.003, autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3 everton_destino(# ); CREATE TABLE everton_destino=# alter table tb_hash_session set (toast.autovacuum_analyze_scale_factor=0.001); ALTER TABLE ( ^ deveria ter dado erro, certo? Talvez isso possa ser reportado como bug. ) Na verdade é um comportamento normal até o momento, ele não gera uma exceção mas também não efetiva a operação alterando a pg_class.reloptions. Há algum tempo implementamos a exceção para o ALTER TABLE RESET que também não alertava [1]. Vou reportar lá e propor um patch para gerar uma exceção nesse caso. Creio que não irão rejeitar. everton_destino=# \d+ tb_hash_session Tabela public.tb_hash_session Coluna |Tipo | Modificadores | Armazenamento | Estat¦sticas | Descri¦¦o -+-+---+---+--+--- id_hash_session | integer | n¦o nulo | plain | | id_pessoa | integer | n¦o nulo | plain | | ds_hash | character varying(40) | n¦o nulo | extended | | dt_expiracao| timestamp without time zone | n¦o nulo | plain | | ds_ip | character varying(40) | n¦o nulo | extended | | T¦m OIDs: n¦o Op¦¦es: autovacuum_enabled=true, autovacuum_analyze_scale_factor=0.001, autovacuum_analyze_threshold=1, autovacuum_vacuum_scale_factor=0.003, autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3 Entretanto o parâmetro não está aplicado, conferir na pg_class.reloptions e também não é exibido. Por esse motivo não é bem um bug... Att, [1] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=73d78e11a0f7183c80b93eefbbb6026fe9664015 -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Espelhamento !!
Bom dia. Gostaria de uma ajuda para resolver um problema de espelhamento de banco, ou replicação !!!?? Minha situação : 1 – Servidor web (Linux). 3 – Servidores (locais – Windows) (lojas).- Locais diferentes. No servidor Linux-web criei uma base de dados para cada (loja), então ficou assim (loja1,loja2,loja3). Preciso que as lojas de tempo em tempo (5,10,15, minutos) não resolvemos ainda atualize a Base de dados do servidor linus. Motivos – segurança – centralizar informação – facilidade em troca de equipamento com defeito. Como posso fazer isso de uma forma transparente para os usuários e que Mande a informação das lojas para o servidor, pois as lojas, pode ficar sem internet, energia, etc.. Obrigado a todos. Salmos 27:13 Pereceria sem dúvida, se não cresse que veria a bondade do Senhor na terra dos viventes. Paulo. --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Espelhamento !!
On 25-08-2015 10:11, Agape World Informática Ltda wrote: Gostaria de uma ajuda para resolver um problema de espelhamento de banco, ou replicação !!!?? Minha situação : 1 – Servidor web (Linux). 3 – Servidores (locais – Windows) (lojas).- Locais diferentes. No servidor Linux-web criei uma base de dados para cada (loja), então ficou assim (loja1,loja2,loja3). Você não explicou se os dados do servidor web vão para servidores locais também. Se a resposta for não, a sua única opção é um software de replicação por gatilhos (a outra opção seria replicação nativa com um cluster por loja mas como são SOs diferentes não é possível fazê-lo). Se a resposta for sim, o seu modelo deve estar adequado para suportar colisão de chaves e você precisa de algum software de replicação que suporte múltiplos mestres (ex. Bucardo). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PGBR2015 - Novos palestrantes confirmados
E as novidades não param. Dois novos palestrantes internacionais confirmados. Teodor Sigaev e Oleg Bartunov. Ambos russos da Postgres Professional. São responsáveis pela estrutura que permite implementação dos índices GiN e GiST no postgres. Mais informações a respeito no site[1] do evento Att; [1] http://pgbr.postgresql.org.br/2015/#speakers ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível bug no PostgreSQL - Storage parameters inválidos do toast são aceitos no ALTER TABLE
Segue abaixo a demonstração do parâmetro não-permitido na tabela que me
referi no primeiro e-mail.
xxx=# \d+ client.tb_hash_session
Table
client.tb_hash_session
Column |Type |
Modifiers | Storage | Stats target | Description
-+-+--+--+--+-
id_hash_session | integer | not null default
nextval('sq_tb_hash_session'::regclass) | plain| |
...
Has OIDs: no
Options: autovacuum_enabled=true, autovacuum_analyze_scale_factor=0.001,
autovacuum_analyze_threshold=1, autovacuum_vacuum_scale_factor=0.003,
autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3,
*toast.autovacuum_analyze_scale_factor*=0.001,
toast.autovacuum_analyze_threshold=1,
toast.autovacuum_vacuum_scale_factor=0.003,
toast.autovacuum_vacuum_threshold=3, toast.autovacuum_vacuum_cost_delay=3
--
Everton
2015-08-25 18:26 GMT-03:00 Everton Berz everton.b...@gmail.com:
Fabrízio
acredito que só aconteça quando as outras propriedades (não toast) estejam
setadas. Veja se consegue reproduzir os comandos abaixo.
Entretanto percebi agora que quando fiz na tabela zerada, apesar de não
emitir erro, o parâmetro não é setado efetivamente.
Fica a dúvida de como na nossa tabela antiga aquele parâmetro foi
injetado. Pode ter acontecido durante algum pg_upgrate ou algo do tipo.
[root@xxx04-bug-db ~]# psql -U postgres everton_destino
psql (9.3.5)
Digite help para ajuda.
everton_destino=# select version();
version
--
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-4), 64-bit
(1 registro)
everton_destino=# CREATE TABLE tb_hash_session (
everton_destino(# id_hash_session integer NOT NULL,
everton_destino(# id_pessoa integer NOT NULL,
everton_destino(# ds_hash character varying(40) NOT NULL,
everton_destino(# dt_expiracao timestamp without time zone NOT NULL,
everton_destino(# ds_ip character varying(40) NOT NULL
everton_destino(# )
everton_destino-# WITH (
everton_destino(# autovacuum_enabled=true,
autovacuum_analyze_scale_factor=0.001, autovacuum_analyze_threshold=1,
everton_destino(# autovacuum_vacuum_scale_factor=0.003,
autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3
everton_destino(# );
CREATE TABLE
everton_destino=# alter table tb_hash_session set
(toast.autovacuum_analyze_scale_factor=0.001);
ALTER TABLE
( ^ deveria ter dado erro, certo? Talvez isso possa ser reportado como
bug. )
everton_destino=# \d+ tb_hash_session
Tabela public.tb_hash_session
Coluna |Tipo | Modificadores |
Armazenamento | Estat¦sticas | Descri¦¦o
-+-+---+---+--+---
id_hash_session | integer | n¦o nulo | plain
| |
id_pessoa | integer | n¦o nulo | plain
| |
ds_hash | character varying(40) | n¦o nulo | extended
| |
dt_expiracao| timestamp without time zone | n¦o nulo | plain
| |
ds_ip | character varying(40) | n¦o nulo | extended
| |
T¦m OIDs: n¦o
Op¦¦es: autovacuum_enabled=true, autovacuum_analyze_scale_factor=0.001,
autovacuum_analyze_threshold=1, autovacuum_vacuum_scale_factor=0.003,
autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3
Entretanto o parâmetro não está aplicado, conferir na pg_class.reloptions
e também não é exibido.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Matar Usuario Postgresql 8l.2
2015-08-24 18:10 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Como faço para parar todos os usuarios do banco postgresql 8.2 Em 2015 e você usando a versão 8.2? Tem gente que gosta de sofrer mesmo... xP Não estou achando. Tenho que fazer o seguinte. - drop no banco. - create - restaurar o banco. Ah... Mais uma coisa que esqueci de mencionar e vou deixar aqui como referência. O que passamos aqui vai funcionar para a grande maioria dos casos, mas tem uma situação bem específica (e bem chata) onde um usuário pode conectar entre o kill e o DROP DATABASE. Mesmo renomeando a base isso pode acontecer em versões mais recentes por causa do autovacuum. Uma forma de se resolver isso é desabilitar a possibilidade de conexão na base fazendo um UPDATE na pg_database: UPDATE pg_database SET datallowconn = false WHERE datname = 'nome_da_base'; -- Fazer o `kill -TERM pid` DROP DATABASE nome_da_base; ... faz o CREATE e a restauração aqui ... Quanto à parte do kill manual na 8.2, você pode fazer via shell: $ psql -c UPDATE pg_database SET datallowconn = false WHERE datname = 'nome_da_base'; $ psql -AXtqc SELECT procpid FROM pg_stat_activity WHERE datname = 'nome_da_base'; | xargs kill -TERM *ATENÇÃO:* em geral não é recomendado fazer atualização em tabelas de catálogo, mas sabe-se que as colunas datallowcon e datistemplate da pg_database são seguras de atualizar, tanto que na versão 9.5 criou-se as opções ALLOW_CONNECTIONS e IS_TEMPLATE no comando ALTER DATABASE para fazer essa operação, assim, na 9.5, ficaria: ALTER DATABASE nome_da_base WITH ALLOW_CONNECTIONS=false; SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'nome_da_base'; DROP DATABASE nome_da_base; Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Monitoramento do Slony
Amigos, Estou tentando realizar monitoramento dos logs no Slony, já vi na documentação que existem alguns plugins para o Nagios, porém nenhum deles funciona conforme documentado. Alguem saberia de uma ferramenta que pudesse realizar este monitoramento de tal forma que a partir de qualquer erro informado nos logs pudesse ser sinalizado para uma ação imediata ? Agradeço a todos. Rogério Cunha Carvalho Muitos são os planos no coração do homem, mas o que prevalece é o propósito do Senhor. Provérbios 19:21 There are many plans in a man's heart; nevertheless the counsel of the LORD, that shall stand. Proverbs 19:21 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [PGBR2015] Sugestões Temas para Fishbowl
Em 18 de agosto de 2015 16:00, Fernando Ike f...@midstorm.org escreveu: On Tue, 2015-08-18 at 14:58 -0300, Fabrízio de Royes Mello wrote: Pessoal, Esse ano estamos com a idéia de promover um Fishbowl [1] dentro do evento, então precisamos de idéias sobre assuntos. Exemplo: - Comunidade PostgreSQL Brasil - Mercado de Trabalho PostgreSQL - Como ajudar o PostgreSQL a crescer - Quero ajudar/me envolver o que faço - DBA 2.0 ou 3.0? - Killer apps para o ecossistema do PostgreSQL? (parafraseando o Roberto Mello em 2013) []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: Matar Usuario Postgresql 8l.2
Muito Obriagdo. Funcionou. De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Matheus de Oliveira Enviada em: terça-feira, 25 de agosto de 2015 09:17 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Matar Usuario Postgresql 8l.2 2015-08-24 18:10 GMT-03:00 Agape World Informática Ltda ag...@agapeworld.com.br: Como faço para parar todos os usuarios do banco postgresql 8.2 Em 2015 e você usando a versão 8.2? Tem gente que gosta de sofrer mesmo... xP Não estou achando. Tenho que fazer o seguinte. - drop no banco. - create - restaurar o banco. Ah... Mais uma coisa que esqueci de mencionar e vou deixar aqui como referência. O que passamos aqui vai funcionar para a grande maioria dos casos, mas tem uma situação bem específica (e bem chata) onde um usuário pode conectar entre o kill e o DROP DATABASE. Mesmo renomeando a base isso pode acontecer em versões mais recentes por causa do autovacuum. Uma forma de se resolver isso é desabilitar a possibilidade de conexão na base fazendo um UPDATE na pg_database: UPDATE pg_database SET datallowconn = false WHERE datname = 'nome_da_base'; -- Fazer o `kill -TERM pid` DROP DATABASE nome_da_base; ... faz o CREATE e a restauração aqui ... Quanto à parte do kill manual na 8.2, você pode fazer via shell: $ psql -c UPDATE pg_database SET datallowconn = false WHERE datname = 'nome_da_base'; $ psql -AXtqc SELECT procpid FROM pg_stat_activity WHERE datname = 'nome_da_base'; | xargs kill -TERM ATENÇÃO: em geral não é recomendado fazer atualização em tabelas de catálogo, mas sabe-se que as colunas datallowcon e datistemplate da pg_database são seguras de atualizar, tanto que na versão 9.5 criou-se as opções ALLOW_CONNECTIONS e IS_TEMPLATE no comando ALTER DATABASE para fazer essa operação, assim, na 9.5, ficaria: ALTER DATABASE nome_da_base WITH ALLOW_CONNECTIONS=false; SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'nome_da_base'; DROP DATABASE nome_da_base; Atenciosamente, -- Matheus de Oliveira --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: Espelhamento !!
Na Web só vou centralizar as informações , não vai para lugar nenhum. Qd precisar vou baixar o banco todo !!! -Mensagem original- De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Euler Taveira Enviada em: terça-feira, 25 de agosto de 2015 10:24 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Espelhamento !! On 25-08-2015 10:11, Agape World Informática Ltda wrote: Gostaria de uma ajuda para resolver um problema de espelhamento de banco, ou replicação !!!?? Minha situação : 1 – Servidor web (Linux). 3 – Servidores (locais – Windows) (lojas).- Locais diferentes. No servidor Linux-web criei uma base de dados para cada (loja), então ficou assim (loja1,loja2,loja3). Você não explicou se os dados do servidor web vão para servidores locais também. Se a resposta for não, a sua única opção é um software de replicação por gatilhos (a outra opção seria replicação nativa com um cluster por loja mas como são SOs diferentes não é possível fazê-lo). Se a resposta for sim, o seu modelo deve estar adequado para suportar colisão de chaves e você precisa de algum software de replicação que suporte múltiplos mestres (ex. Bucardo). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Espelhamento !!
On 25-08-2015 10:33, Agape World Informática Ltda wrote: Na Web só vou centralizar as informações , não vai para lugar nenhum. Qd precisar vou baixar o banco todo !!! Evite top-posting! Eu lhe aconselharia usar o mesmo sistema operacional para que utilizasse a replicação nativa. Isso evitaria uma série de limitações contornáveis ou não (gatilhos nas tabelas, usuários, alteração de tabelas, ...). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: RES: Espelhamento !!
Infelizmente não tenho como fazer isso. Maquinas nas lojas Windows 7. Web servidor Linux. E não tem como mudar isso, esse é um dos meus grandes problemas. Ainda não sei como proceder para fazer isso funcionar. Nem quais ferramentas usar. -Mensagem original- De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Euler Taveira Enviada em: terça-feira, 25 de agosto de 2015 10:39 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] RES: Espelhamento !! On 25-08-2015 10:33, Agape World Informática Ltda wrote: Na Web só vou centralizar as informações , não vai para lugar nenhum. Qd precisar vou baixar o banco todo !!! Evite top-posting! Eu lhe aconselharia usar o mesmo sistema operacional para que utilizasse a replicação nativa. Isso evitaria uma série de limitações contornáveis ou não (gatilhos nas tabelas, usuários, alteração de tabelas, ...). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral --- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível bug no PostgreSQL - Storage parameters inválidos do toast são aceitos no ALTER TABLE
On 25-08-2015 18:33, Everton Berz wrote:
Segue abaixo a demonstração do parâmetro não-permitido na tabela que me
referi no primeiro e-mail.
xxx=# \d+ client.tb_hash_session
Table
client.tb_hash_session
Column |Type |
Modifiers | Storage | Stats target | Description
-+-+--+--+--+-
id_hash_session | integer | not null default
nextval('sq_tb_hash_session'::regclass) | plain| |
...
Has OIDs: no
Options: autovacuum_enabled=true, autovacuum_analyze_scale_factor=0.001,
autovacuum_analyze_threshold=1, autovacuum_vacuum_scale_factor=0.003,
autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3,
*toast.autovacuum_analyze_scale_factor*=0.001,
toast.autovacuum_analyze_threshold=1,
toast.autovacuum_vacuum_scale_factor=0.003,
toast.autovacuum_vacuum_threshold=3, toast.autovacuum_vacuum_cost_delay=3
Nesse caso o seu catálogo deve ter sido alterado diretamente. Um
update na pg_class setando a coluna reloptions pode fazer isso. Já
vi muito isso ser feito porque o ALTER TABLE ... SET (...) exige um
AccessExclusiveLock até a 9.5. Felizmente para a 9.6 relaxamos o nível
de lock [1] para setar propriedades de autovacuum.
Para te ajudar segue uma pequena PL para remover do catálogo um
reloption de uma relação:
CREATE OR REPLACE FUNCTION del_reloption(relid OID, option TEXT)
RETURNS TEXT[] AS
$$
DECLARE
options TEXT[];
new_options TEXT[];
BEGIN
SELECT reloptions
INTO options
FROM pg_class
WHERE oid = relid
FOR UPDATE;
IF options IS NULL THEN
RETURN NULL;
END IF;
FOR i IN 1..array_upper(options, 1)
LOOP
IF option IS DISTINCT FROM trim(split_part(options[i], '=', 1)) THEN
new_options := array_append(new_options, options[i]);
END IF;
END LOOP;
UPDATE pg_class
SETreloptions = new_options
WHERE oid = relid;
RETURN new_options;
END;
$$
LANGUAGE plpgsql;
Para utilizar a PL acima basta:
SELECT del_reloption('tb_hash_session'::regclass,
'toast.autovacuum_analyze_scale_factor');
E caso vc queira varrer todas suas tabelas pode também:
SELECT del_reloption(relid, 'toast.autovacuum_analyze_scale_factor')
FROM pg_stat_user_tables;
Espero ter ajudado...
Att,
Ps: o patch em [1] foi financiado por uma empresa brasileira
(http://zenvia.com.br) e também desenvolvido por um brasileiro.
[1]
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=47167b7907a802ed39b179c8780b76359468f076
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
