[pgbr-geral] Instalação do Postgis x Postgresql 9.4

[Leandro]

Pessoal boa noite, alguem que manja de instalação de postgis e linux,
estou tentando compilar a o postgis 2.1 em um RH7 mas estou esbarrando
em algum problema nas dependencias do postgis.  Quando vou executar o
comando abaixo:
postgis-2.1.5]# ./configure
--with-pgconfig=/opt/rh/rh-postgresql94/root/usr/bin/pg_config

Apresenta o seguinte erro:
checking for library containing GDALAllRegister... no
configure: error: could not find GDAL

Já instalei o GDAL se alguem tiver alguma dica agradeço muito

att,

Leandro
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[Sebastian Webber]

Em 1 de abril de 2016 14:07,  escreveu:


>
> Vou verificar aqui se mais de um usuário está usando essa rotina de Update
> por demanda, pois pode estar aí o problema.
>
>
Chegastes a monitorar as consultas lentas pra validar se o que está
acontecendo é um lock no registro ou algo especifico no sistema? Nenhuma
operação de UPDATE/DELETE vai impedir os dados de serem lidos.

Acho interessante acompanhar as consultas e ver o comportamento do banco
nos horários de travamento. Caso possível, passe a monitorar os locks
através do exemplo abaixo:

https://wiki.postgresql.org/wiki/Lock_Monitoring

[]'s

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 2 de abril de 2016 00:07, Sebastian Webber 
escreveu:


> Pelo que vi no GitHub[1], o commit que foi implementado o suporte ao RDS
> já foi feito merge. Certeza que está usando a versão mais recente?
>
> [1]
> https://github.com/julmon/pg_activity/commit/759bad22d6def7bd265794ba57105bb33306a761
>
>
O commit correto era esse:

https://github.com/julmon/pg_activity/commit/8f46c2251ee5295e34754f8a2b87a606556d3af7


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 1 de abril de 2016 09:38, Cleiton Luiz Domazak 
escreveu:

> Alguém utiliza o pg_activity em bancos rodando no RDS?
>
> Por conta da estrutura de permissões do RDS ele acaba não permitindo o
> acesso default do pg_activity, já vi alguns foruns e nada funcionou.
>
> Inclusive existe um fork[1] do pg_activity para contornar essa situação e
> mesmo assim não funcionou.
>
> *[1] - https://github.com/julmon/pg_activity
> *
>


Velho, sabe dizer quais as views que ele precisa permissão?

Lembro que é possível conectar remotamente, mas nunca cheguei a usar.

Pelo que vi no GitHub[1], o commit que foi implementado o suporte ao RDS já
foi feito merge. Certeza que está usando a versão mais recente?

[1]
https://github.com/julmon/pg_activity/commit/759bad22d6def7bd265794ba57105bb33306a761





-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Cleiton Luiz Domazak]

Agora voltando ao assunto do e-mail.

Alguém ?

2016-04-01 13:11 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org>:

> 2016-04-01 12:55 GMT-03:00 Mario Moreira :
> > Boa tarde a todos. Como faço, ou o que devo fazer realmente para não
> receber
> > mais NENHUM email dessa Comunidade, pois já realizei os procedimentos de
> > desinscrição apenas 11 vezes.
>
> E cadê o relato de erro?  Como no PostgreSQL em si, é um procedimento
> técnico: até que passo você chegou, qual foi a última mensagem do
> processo que recebeu…
>
>
> > A Comunidade POSTGRESQL é de uma maestria
> > enorme e ajuda muita gente e muitas empresas, agradeço muito todo
> > ensinamento compartilhado mas não desejo mais receber emails dessa
> > Comunidade, então Leandro Dutra, Rodrigo Horj e outros administradores
> por
> > favor retirem meu email da lista, obrigado.
>
> Sinto decepcionar mas não sou administrador… nem sei quem são, hoje.
>
>
> --
> 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
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Abertas Inscrições para o DBA-Brasil 1.0

[Fábio Telles Rodriguez]

Só para avisar, como já temos mais de 400  inscritos, pode ser que tenhamos
que fechar as inscrições em breve... portanto corram!

Aproveita e dá uma olhada na grade! 2 dos nossos Hackers do PostgreSQL
estarão lá.

Em 21 de março de 2016 09:45, Kenia Milene  escreveu:

> Pessoal,
>
> Estão abertas as inscrições para o DBA-BRasil 1.0
> Aguardamos todos vocês la !!! Avisem os cachorros papagaios e vizinhos
> http://dbabrasil1.0.dbabr.com.br
>
> Kenia Milene Cenizo Galiego
> DataBase Specialist
> Oracle / PostgreSQL / MySql / SQLServer
> Fone: 11 97651-4261
> Email: keniamil...@gmail.com
> Gtalk: keniamil...@gmail.com
>
> Twitter: @keniamilene
> Skype: kenia_milene
> Blog: http://keniamilene.wordpress.com
> MSN: kenia_mil...@hotmail.com
> Facebook: http://www.facebook.com/keniamilene
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// s
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[Shander Lyrio]

Em 1 de abril de 2016 13:33,  escreveu:

> Pessoal tenho uma função no sistema onde o usuario seleciona varios
> produtos e muda por exemplo a localização,
> imagine que seja 2mil produtos, neste momento o caixa está vendendo e aí
> trava,
> isso seria normal ou tem alguma coisa que posso mudar pra não travar o
> registro enquanto altera?
>
> Eu poderia travar no caixa lá é prioridade, pois o cliente já está com o
> produto na mão, mas lá é só select.
>


Exatamente porque caixa é prioridade que não é desta forma que este tipo de
sistema é feito, pelo menos não os bons sistemas.

Normalmente o caixa tem um computador com no-break e bateria para garantir
que ele funcione mesmo em caso de queda de energia. Existe um banco de
dados local no caixa, não precisa ter todos os dados, apenas os necessários
para a venda, neste banco local as vendas são acumuladas para posterior
sincronismo com o banco de dados central, baixa em estoque, etc... Este
sincronismo pode acontecer o tempo todo enquanto houver energia, mas pode
ficar temporariamente parado em caso de queda de rede.

Os preços não são alterados o tempo todo, então a informação de preço pode
e deve ficar armazenado no caixa localmente e ser sincronizado de tempos em
tempos.

Então num caso destes, antes de procurar fazer peripércias no banco de
dados, é melhor dar uma olhadinha se a infra está de acordo com o tipo de
serviço. Para este tipo de serviço, normalmente não é desta forma que se
desenvolve o sistema.

​Abraço,​


--
​Shander Lyrio​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACCUM FULL linhas deletadas não sendo apagadas

[Luiz Carlos L. Nogueira Jr.]

O banco não está sendo utilizado e só tem minha conexão nele.

Por desencargo de consciência fui rodar o vacuum full de novo e notei que
agora funcionou.

De manhã fiz o vacuum full
INFO:  vacuuming "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": found 0 removable, 12691251 nonremovable
row versions in 225883 pages
DETAIL:  *178441 dead row versions cannot be removed yet.*
CPU 5.47s/10.12u sec elapsed 16.81 sec.
INFO:  analyzing "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": scanned 225883 of 225883 pages, containing
12512810 live rows and *178441 dead rows;* 30 rows in sample, 12512810
estimated total rows
Query returned successfully with no result in 445379 ms.

Agora fiz de novo

INFO:  vacuuming "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": found 178441 removable, 12512810
nonremovable row versions in 225883 pages
DETAIL:  *0 dead row versions cannot be removed yet*.
CPU 7.09s/11.22u sec elapsed 23.57 sec.
INFO:  "jbpm_variableinstance": scanned 222962 of 222962 pages, containing
12512810 live rows and *0 dead rows;* 30 rows in sample, 12512810
estimated total rows
Query returned successfully with no result in 465956 ms.




Será que o autovacuum (ou algum outro processo interno do postgres) poderia
estar "lockando" essas linhas que não puderam ser removidas no vacuum?

Acho que essa seria a explicação mais lógica, mas é achismo..
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[sistemas]

-Mensagem Original- 
From: Tiago José Adami

Sent: Friday, April 1, 2016 1:52 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Como tratar a concorrencia Update x Select

Em 1 de abril de 2016 13:33,   escreveu:
Pessoal tenho uma função no sistema onde o usuario seleciona varios 
produtos

e muda por exemplo a localização,
imagine que seja 2mil produtos, neste momento o caixa está vendendo e aí
trava,
isso seria normal ou tem alguma coisa que posso mudar pra não travar o
registro enquanto altera?

Eu poderia travar no caixa lá é prioridade, pois o cliente já está com o
produto na mão, mas lá é só select.

Como o PostgreSQL trava essas concorrências?


Para responder esta pergunta são necessárias algumas informações:

1) Qual a versão do PostgreSQL utilizada?

9.1

2) Qual o nível de isolação (isolation level) utilizado nos caixas [1]?

Eu uso um componente chamado Zeos no delphi e nele está a opção 
TransactionLevel = tiNone, ou seja ele deixa o postgres decidir, então deve 
ser o padrão.

As opções são:

tiNone
tiReadCommitted
tiReadUncommitted
tiRepeatableRead
tiSerializable

Curioso eu achei que estivesse tiReadCommitted, pois é o que normalmente 
uso.


3) O comando SELECT que busca o produto no caixa está utilizando a
cláusula FOR UPDATE?

Não

4) O processo de venda atualiza o valor de alguma coluna na tabela de 
produtos?


Não

O nível de isolação padrão é READ COMMITED. Neste caso você não teria
problemas exceto se há concorrência de UPDATE/DELETE sobre o mesmo
registro sendo alterado no cadastro e na venda.

Vou verificar aqui se mais de um usuário está usando essa rotina de Update 
por demanda, pois pode estar aí o problema.


Marcelo Silva


[1] http://www.postgresql.org/docs/current/static/sql-set-transaction.html

TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[Tiago José Adami]

Em 1 de abril de 2016 13:33,   escreveu:
> Pessoal tenho uma função no sistema onde o usuario seleciona varios produtos
> e muda por exemplo a localização,
> imagine que seja 2mil produtos, neste momento o caixa está vendendo e aí
> trava,
> isso seria normal ou tem alguma coisa que posso mudar pra não travar o
> registro enquanto altera?
>
> Eu poderia travar no caixa lá é prioridade, pois o cliente já está com o
> produto na mão, mas lá é só select.
>
> Como o PostgreSQL trava essas concorrências?

Para responder esta pergunta são necessárias algumas informações:

1) Qual a versão do PostgreSQL utilizada?
2) Qual o nível de isolação (isolation level) utilizado nos caixas [1]?
3) O comando SELECT que busca o produto no caixa está utilizando a
cláusula FOR UPDATE?
4) O processo de venda atualiza o valor de alguma coluna na tabela de produtos?

O nível de isolação padrão é READ COMMITED. Neste caso você não teria
problemas exceto se há concorrência de UPDATE/DELETE sobre o mesmo
registro sendo alterado no cadastro e na venda.

[1] http://www.postgresql.org/docs/current/static/sql-set-transaction.html

TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Como tratar a concorrencia Update x Select

[sistemas]

Pessoal tenho uma função no sistema onde o usuario seleciona varios produtos e 
muda por exemplo a localização, 
imagine que seja 2mil produtos, neste momento o caixa está vendendo e aí trava, 
isso seria normal ou tem alguma coisa que posso mudar pra não travar o registro 
enquanto altera?

Eu poderia travar no caixa lá é prioridade, pois o cliente já está com o 
produto na mão, mas lá é só select.

Como o PostgreSQL trava essas concorrências?


Marcelo Silva___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-01 12:55 GMT-03:00 Mario Moreira :
> Boa tarde a todos. Como faço, ou o que devo fazer realmente para não receber
> mais NENHUM email dessa Comunidade, pois já realizei os procedimentos de
> desinscrição apenas 11 vezes.

E cadê o relato de erro?  Como no PostgreSQL em si, é um procedimento
técnico: até que passo você chegou, qual foi a última mensagem do
processo que recebeu…


> A Comunidade POSTGRESQL é de uma maestria
> enorme e ajuda muita gente e muitas empresas, agradeço muito todo
> ensinamento compartilhado mas não desejo mais receber emails dessa
> Comunidade, então Leandro Dutra, Rodrigo Horj e outros administradores por
> favor retirem meu email da lista, obrigado.

Sinto decepcionar mas não sou administrador… nem sei quem são, hoje.


-- 
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] pg_activity em Amazon RDS

[Mario Moreira]

Boa tarde a todos. Como faço, ou o que devo fazer realmente para não
receber mais NENHUM email dessa Comunidade, pois já realizei os
procedimentos de desinscrição apenas 11 vezes. A Comunidade POSTGRESQL é de
uma maestria enorme e ajuda muita gente e muitas empresas, agradeço muito
todo ensinamento compartilhado mas não desejo mais receber emails dessa
Comunidade, então Leandro Dutra, Rodrigo Horj e outros administradores por
favor retirem meu email da lista, obrigado.
Em 1 de abr de 2016 09:38, "Cleiton Luiz Domazak" 
escreveu:

> Alguém utiliza o pg_activity em bancos rodando no RDS?
>
> Por conta da estrutura de permissões do RDS ele acaba não permitindo o
> acesso default do pg_activity, já vi alguns foruns e nada funcionou.
>
> Inclusive existe um fork[1] do pg_activity para contornar essa situação e
> mesmo assim não funcionou.
>
> *[1] - https://github.com/julmon/pg_activity
> *
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] pg_activity em Amazon RDS

[Cleiton Luiz Domazak]

Alguém utiliza o pg_activity em bancos rodando no RDS?

Por conta da estrutura de permissões do RDS ele acaba não permitindo o
acesso default do pg_activity, já vi alguns foruns e nada funcionou.

Inclusive existe um fork[1] do pg_activity para contornar essa situação e
mesmo assim não funcionou.

*[1] - https://github.com/julmon/pg_activity
*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Flavio Henrique Araque Gurgel]

select version();
PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit


9.3.4 -> 9.3.12
O release notes que te mandei já é da 9.3.6, você está bemm 
atrasado. Atualiza e depois nos diz se seu problema foi resolvido. Senão 
talvez tenhamos de ir lá na lista internacional, ou talvez a turma da 
Timbira tenha alguma ideia, eles estão mais por dentro do código que eu.



select * from pg_prepared_xacts
Sem linhas afetadas



Obrigado, não é teu caso.

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Luiz Carlos L. Nogueira Jr.]

Completando

WITH list(file) AS (SELECT * FROM pg_ls_dir('pg_multixact/offsets'))
SELECT EXISTS (SELECT * FROM list WHERE file = '') AND
   NOT EXISTS (SELECT * FROM list WHERE file = '0001') AND
   NOT EXISTS (SELECT * FROM list WHERE file = '') AND
   EXISTS (SELECT * FROM list WHERE file != '')
   AS file__removal_required;

f
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Luiz Carlos L. Nogueira Jr.]

Flávio,

select version();
PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-4), 64-bit

select * from pg_prepared_xacts
Sem linhas afetadas
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Flavio Henrique Araque Gurgel]

Em qui, 31 de mar de 2016 22:28, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> versão 9.3
>
> Nesse contexto isso não é relavante.
>
> --É relevante porque eu garanto que não estão sendo incluídas nem apagadas
> as linhas. (pra naõ termos distorções nos valores)
>
> Durante a execução do ANALYZE o processo é feito por amostragem, limitadas
> em até 30.000 linhas. Dessas linhas, ele estima que 12486234 são vivas (ou
> seja, estão validas) e 3070018 estão mortas (ou invalidas). Isso
> normalmente quer dizer que tua tabela está inchada devido ao comportamento
> do MVVC.
>
> --Nas duas tabelas foi feito um vacuum full antes, não devendo mais
> aparecer linhas mortas
>
> Oi Luiz

Verifique duas coisas, a primeira, qual a versão completa? Existe um bug já
corrigido que tem relação com vacuum, veja este release notes:
http://www.postgresql.org/docs/9.4/static/release-9-3-5.html

Se for seu caso, siga as instruções ao atualizar removendo o arquivo
indicado.

A segunda, me recordo que sua aplicação é escrita em Java. Veja se por
acaso não estão usando transações preparadas com um select na visão
pg_prepared_xacts

Se alguma transação não foi corretamente encerrada ela fica no servidor de
banco indefinidamente. Isso deixa locks, mesmo sem outros usuários
conectados e mesmo se o servidor foi reiniciado. Aí as tuplas não são
removidas.

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral