Re: [pgbr-geral] Plpgsql function Postgres 9.5

2016-12-14 Por tôpico Patrick B
2016-12-15 13:38 GMT+13:00 Patrick B :

> Olá,
>
> Eu possuo a seguinte query:
>
> COPY (
>
> SELECT
>
> uuid,
>
> clientid,
>
> *
>
> FROM
>
> logging
>
> WHERE
>
> logtime
>
> BETWEEN
>
> '201611015'
>
> AND
>
> '201612015' ) TO '/var/lib/postgresql/arquivo.csv';
>
>
> Esta query tem que ser manualmente rodada 1x por mês. Por esta razão,
> estou fazendo uma PLPGSQL function para que isso seja automatizado.
>
> CREATE or REPLACE FUNCTION lextract(date_end text)
>
> RETURNS void AS $$
>
>
> DECLARE
>
> date_start date := CURRENT_DATE;
>
>
> begin
>
>   execute '
>
>   COPY
>
>   (
>
> SELECT
>
> uuid,
>
> clientid,
>
> *
>
> FROM
>
> logging
>
> WHERE
>
> logtime
>
> BETWEEN
>
> ' || date_start || '
>
> AND
>
> ' || date_end || '
>
>   )
>
>   TO ''/var/lib/postgresql/'|| date_start ||'_logs.csv''';
>
> end
>
> $$ language 'plpgsql';
>
>
>
> Quando chamo a function, recebo este erro:
>
> select lextract('201611015');
>
> ERROR:  operator does not exist: timestamp without time zone >= integer
>
> LINE 13: BETWEEN
>
>  ^
>
> HINT:  No operator matches the given name and argument type(s). You might
>> need to add explicit type casts.
>
>
> No que estou falhando? Obrigado!
>




Consegui resolver da seguinte forma:

BETWEEN
''' || date_start || '''
AND
''' || date_end || '''


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

[pgbr-geral] Plpgsql function Postgres 9.5

2016-12-14 Por tôpico Patrick B
Olá,

Eu possuo a seguinte query:

COPY (

SELECT

uuid,

clientid,

*

FROM

logging

WHERE

logtime

BETWEEN

'201611015'

AND

'201612015' ) TO '/var/lib/postgresql/arquivo.csv';


Esta query tem que ser manualmente rodada 1x por mês. Por esta razão, estou
fazendo uma PLPGSQL function para que isso seja automatizado.

CREATE or REPLACE FUNCTION lextract(date_end text)

RETURNS void AS $$


DECLARE

date_start date := CURRENT_DATE;


begin

  execute '

  COPY

  (

SELECT

uuid,

clientid,

*

FROM

logging

WHERE

logtime

BETWEEN

' || date_start || '

AND

' || date_end || '

  )

  TO ''/var/lib/postgresql/'|| date_start ||'_logs.csv''';

end

$$ language 'plpgsql';



Quando chamo a function, recebo este erro:

select lextract('201611015');

ERROR:  operator does not exist: timestamp without time zone >= integer

LINE 13: BETWEEN

 ^

HINT:  No operator matches the given name and argument type(s). You might
> need to add explicit type casts.


No que estou falhando? Obrigado!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidao em consulta usando Between com datas iguais

2016-12-14 Por tôpico Tiago José Adami
Em 14 de dezembro de 2016 16:43, Cleiton Luiz Domazak
 escreveu:
> Nem index tinha, criei e ele não é utilizado.

Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a
definição (comando) que você usou para criar o índice?

>
> Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre no meu 
> ambiente de testes. E ocorre em situações um pouco aleatórias.
>
> Essas são as datas que eu usei e se funcionou ou não. Muito esquisito.
>
> AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK
> AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK
> AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK
> AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK
> AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK
> AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK

Qual a quantidade de registros total na tabela e a média mensal?

Primeiro execute um VACUUM ANALYZE sobre a tabela como mencionei antes
e depois roda um EXPLAIN para vermos o que o plano de acesso está
fazendo para pelo menos uma consulta que ficou OK e para a NOK.

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

Re: [pgbr-geral] Conversão de data em 2 dígitos (Default Century)

2016-12-14 Por tôpico Alexsandro Haag

Em 14/12/2016 16:23, Euler Taveira escreveu:

Só alterando o código (formatting.c:adjust_partial_year_to_2020). Eu não
alteraria. Até porque isso não vai mudar no postgres e duvido que
aceitem um patch que vai gerar incompatibilidade. Ao invés disso, é como
o Flavio disse, eu forçaria o cliente a alterar a aplicação. Para que as
coisas não parem de funcionar, se for o caso, eu adotaria um gatilho.
Euler,  estou considerando isso. Alterar e gerar uma versão para o 
cliente. Mas não propor nenhum patch disso.


Eles vão precisar alterar o código em vários pontos do sistema. Esta 
alteração daria um tempo para que a sua equipe possa concluir esta 
tarefa de revisão.


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

Re: [pgbr-geral] Conversão de data em 2 dígitos (Default Century)

2016-12-14 Por tôpico Alexsandro Haag


Em 14/12/2016 15:50, Flavio Henrique Araque Gurgel escreveu:
Eu colocaria uma Trigger na tabela e escreveria uma função rápida pra 
tratar essa coluna específica.


Note apenas que esse tipo de remendo pode levar à "solução paliativa 
definitiva" e seu cliente jamais consertar o lado dele.
Sim Flávio, já estão com uma solução paliativa. Enviei para o grupo para 
ver se nada estava me escapando.


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

Re: [pgbr-geral] Instalação do PostgreSQL em Mac

2016-12-14 Por tôpico Flaudísio Tolentino
>
> Vocês teriam um tutorial de instalação do postgres no mac (versão
> yosemite)?
>

A página de download​
​[1] tem várias opções; sugiro começar por lá.

Qual a melhor forma de instalar?
>

Só uma dica: após ver os métodos "padrões" e se você quiser criar e remover
instâncias "voláteis" do Postgres (como é o caso de ambientes de
desenvolvimento), o Docker[2][3] pode ser uma opção. Apenas fique atento
aos pré-requisitos do macOS.

[1] https://www.postgresql.org/download/macosx/​​
[2] https://docs.docker.com/engine/installation/mac/
[3] https://hub.docker.com/_/postgres/


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

Re: [pgbr-geral] Forma de resolver um travamento

2016-12-14 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
2016-12-14 14:37 GMT-02:00 Leonardo Coleraus :
>
> Boa Tarde Amigos,

Em vez de formatar, pode escrever texto simples mesmo, mas escreva
corretamente, com pontuação e, se possível, acentuação.  Fica melhor
para lermos, entendermos e, se pudermos, ajudarmos.


-- 
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] Lentidao em consulta usando Between com datas iguais

2016-12-14 Por tôpico Cleiton Luiz Domazak
2016-12-12 14:56 GMT-02:00 Cleiton Luiz Domazak :

>
>
> 2016-12-12 14:04 GMT-02:00 Tiago José Adami :
>
>> Em 12 de dezembro de 2016 11:45, Cleiton Luiz Domazak
>>  escreveu:
>> > (corte)
>> > Alguém já passou por essa situação?
>>
>
>
>> Eu já: com o PostgreSQL 9.4 (não lembro se era 9.4.2 ou 9.4.3). Nas
>> últimas releases, por exemplo a 9.4.8 que uso no ambiente de testes
>> (com mesmo SO), o problema não ocorre.
>>
>> No meu caso havia uma tabela PUBLIC.RESERVA com um atributo chamado
>> "DATA" tipo DATE.
>>
>
> Meu caso é mais misterioso, pq se eu aumento o meu range de data, funciona
> super rapido, quando deveria ser ao contrário :)
>
>>
>> Como o servidor (hardware) é fraquinho eu me antecipei e criei vários
>> índices parciais por ano contendo a cláusula "WHERE DATA BETWEEN
>> '-01-01' AND '-12-31'" (substituindo  pelos anos de 2014
>> até 2020). A cláusula between do ano era usada em todas as consultas
>> envolvendo o atributo DATA.
>>
>> Adicionalmente a estes índices anuais ainda existia um índice composto
>> com o atributo DATA, sendo ele o primeiro da lista de atributos do
>> índice.
>>
>> Sofri um tempão para descobrir o problema. Como é utilizado um
>> servidor Debian e o PostgreSQL dos repositórios oficiais a atualização
>> dos binários demorou um pouco para sair, então tive que encontrar a
>> solução "na mão", que foi excluir os índices parciais deixando apenas
>> um índice "normal" utilizando o atributo "DATA".
>>
>> Sendo assim:
>>
>> 1) Certifique-se de estar utilizando a última release da versão 9.4;
>>
>
O servidor está na 9.4.9 e infelizmente não tenho como atualizar ele nos
próximos dias.

>
> Vou atualizar para a ultima release.
>
>>
>> 2) Verifique se existem índices parciais sobre este atributo de data;
>>
>
Nem index tinha, criei e ele não é utilizado.

>
>> 3) Teste em outro ambiente com o mesmo SO se o problema ocorre após
>> importar um arquivo de DUMP;
>>
>> 3.1) Caso no ambiente de testes funcione, você pode cogitar a
>> possibilidade de fazer um DUMP completo, apagar o banco de dados,
>> criar um novo e reimportar o DUMP no mesmo servidor. Se houver algo
>> corrompido isto deve resolver;
>>
>
> Já pedi para o cliente um dump para eu fazer um teste de restore, pq estou
> achando que seja realmente alguma coisa que possa ser resolvida com um
> dump/restore
>
>>
>>
Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre no meu
ambiente de testes. E ocorre em situações um pouco aleatórias.

Essas são as datas que eu usei e se funcionou ou não. Muito esquisito.

AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK
AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK
AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK
AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK
AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK
AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK


>
>> Adami
>>
>
> Vlw Adami, muito obrigado. Vou realizar esses testes e volto a
> compartilhar com vocês o que tive que resultados.
>
>> ___
>> 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] Instalação do PostgreSQL em Mac

2016-12-14 Por tôpico Cleiton Luiz Domazak
2016-12-14 16:35 GMT-02:00 Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org>:

> 2016-12-14 14:25 GMT-02:00 Danilo Silva :
> >
> > Vocês teriam um tutorial de instalação do postgres no mac (versão
> yosemite)?
> >
> > Qual a melhor forma de instalar?
>
> Provavelmente há pouquíssima gente aqui que faz isso.  Eu
> particularmente olharia o brew.
>
> Eu particularmente subo uma VM linux e instalo.

Mas já cheguei a usar no Mac o Postgres.app [1]

1- http://postgresapp.com/


>
> --
> 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] Instalação do PostgreSQL em Mac

2016-12-14 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
2016-12-14 14:25 GMT-02:00 Danilo Silva :
>
> Vocês teriam um tutorial de instalação do postgres no mac (versão yosemite)?
>
> Qual a melhor forma de instalar?

Provavelmente há pouquíssima gente aqui que faz isso.  Eu
particularmente olharia o brew.


-- 
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] Conversão de data em 2 dígitos (Default Century)

2016-12-14 Por tôpico Euler Taveira
On 14-12-2016 14:27, Alexsandro Haag wrote:
> Gostaria de usar como base por exemplo 2030 e não 2020 para que o
> cliente ganhe mais um tempo até corrigir a sua aplicação.
> 
Só alterando o código (formatting.c:adjust_partial_year_to_2020). Eu não
alteraria. Até porque isso não vai mudar no postgres e duvido que
aceitem um patch que vai gerar incompatibilidade. Ao invés disso, é como
o Flavio disse, eu forçaria o cliente a alterar a aplicação. Para que as
coisas não parem de funcionar, se for o caso, eu adotaria um gatilho.


-- 
   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

Re: [pgbr-geral] Conversão de data em 2 dígitos (Default Century)

2016-12-14 Por tôpico Flavio Henrique Araque Gurgel
Em qua, 14 de dez de 2016 18:28, Alexsandro Haag 
escreveu:

> Boa tarde Pessoal,
>
> sabem se existe algum parâmetro que possa alterar este comportamento, ou
> somente alteração no core?
>
> select cast('01/01/70' as date) , cast('01/01/69' as date);
>
>  date|date
> +
>   1970-01-01 | 2069-01-01
>
> O link de documentação:
> https://www.postgresql.org/docs/9.4/static/functions-formatting.html
> Diz o seguinte: "If the year format specification is less than four
> digits, e.g. YYY, and the supplied year is less than four digits, the
> year will be adjusted to be nearest to the year 2020, e.g. 95 becomes
> 1995."
>
> Gostaria de usar como base por exemplo 2030 e não 2020 para que o
> cliente ganhe mais um tempo até corrigir a sua aplicação.
>

Eu colocaria uma Trigger na tabela e escreveria uma função rápida pra
tratar essa coluna específica.

Note apenas que esse tipo de remendo pode levar à "solução paliativa
definitiva" e seu cliente jamais consertar o lado dele.

[]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] Forma de resolver um travamento

2016-12-14 Por tôpico Cleiton Luiz Domazak
2016-12-14 15:04 GMT-02:00 Leonardo Coleraus :

> Usamos o CentOS release 6.2 (Final) x64
>
> para fazer os destravamento vou no pgAdmin em Tools Server Status e vejo
> qual Blocked by esta travando e mato a o PID assim destravo o banco, nao
> olhei os logs ainda referente a isso.
>

Na verdade você apenas está eliminando uma transação que está gerando um
LOCK [1], isso não é o travamento do banco. Veja no log que query é essa
que gera sempre o LOCK, se é gerado pelo mesmo client ou é geral, coisas do
tipo.

Imagino que a aplicação esteja realizando alguma escrita no banco(isso gera
um LOCK), e talvez essa conexão fique "perdida" e a transação não é
finalizada corretamente. Ou ainda pode ocorrer da aplicação ficar
transacionada no banco até que o usuário finalize alguma operação, e esse
usuário deixa a tela aberta, mantendo o LOCK na tabela. As possibilidades
são infinitas.

Com isso você poderá identificar com mais precisão em que situação a sua
aplicação está gerando esse LOCK no banco. E você deverá conhecer a forma
que a sua aplicação trabalha com o banco.

[1] - https://www.postgresql.org/docs/9.4/static/explicit-locking.html

> Em 14/12/2016 14:44, Cleiton Luiz Domazak escreveu:
>
>
>
> 2016-12-14 14:37 GMT-02:00 Leonardo Coleraus :
>
>> Boa Tarde Amigos,
>>
>> Estou tendo um problema aqui na empresa, o que acontece.
>>
>> Os Caixa ao emitir as NF-e Danfe, dependendo o momento do dia acontece um
>> travamento no banco, onde hoje vou la no PGAdmin e destravo manualmente,
>> mas  quero ajuda de vocês* pra saber qual a melhor forma de saber porque
>> esse travamento por onde posso começar a diagnosticar pra poder ser
>> resolvido esse problema* que esta ocasionando bastante problema, pois
>> não SO trava os Caixa e sim toda a empresa.
>>
>> Usamos o PostgreSQL 9.3 com o ERP Adempiere com 190 conexões
>>
> O que aparece no log do PostgreSQL?
>
> Qual o SO, x64?
>
> Você pode descrever melhor como que é esse processo de destravar pelo
> pgAdmin?
>
>
>> Grato
>>
>>
>>
>> --
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> ___
> pgbr-geral mailing 
> listpgbr-ge...@listas.postgresql.org.brhttps://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 mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Conversão de data em 2 dígitos (Default Century)

2016-12-14 Por tôpico Alexsandro Haag

Boa tarde Pessoal,

sabem se existe algum parâmetro que possa alterar este comportamento, ou 
somente alteração no core?


select cast('01/01/70' as date) , cast('01/01/69' as date);

date|date
+
 1970-01-01 | 2069-01-01

O link de documentação: 
https://www.postgresql.org/docs/9.4/static/functions-formatting.html
Diz o seguinte: "If the year format specification is less than four 
digits, e.g. YYY, and the supplied year is less than four digits, the 
year will be adjusted to be nearest to the year 2020, e.g. 95 becomes 1995."


Gostaria de usar como base por exemplo 2030 e não 2020 para que o 
cliente ganhe mais um tempo até corrigir a sua aplicação.


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

Re: [pgbr-geral] Forma de resolver um travamento

2016-12-14 Por tôpico Leonardo Coleraus

Usamos o CentOS release 6.2 (Final) x64

para fazer os destravamento vou no pgAdmin em Tools Server Status e vejo 
qual Blocked by esta travando e mato a o PID assim destravo o banco, nao 
olhei os logs ainda referente a isso.


Em 14/12/2016 14:44, Cleiton Luiz Domazak escreveu:



2016-12-14 14:37 GMT-02:00 Leonardo Coleraus >:


Boa Tarde Amigos,

Estou tendo um problema aqui na empresa, o que acontece.

Os Caixa ao emitir as NF-e Danfe, dependendo o momento do dia
acontece um travamento no banco, onde hoje vou la no PGAdmin e
destravo manualmente, mas quero ajuda de vocês*pra saber qual a
melhor forma de saber porque esse travamento por onde posso
começar a diagnosticar pra poder ser resolvido esse problema* que
esta ocasionando bastante problema, pois não SO trava os Caixa e
sim toda a empresa.

Usamos o PostgreSQL 9.3 com o ERP Adempiere com 190 conexões

O que aparece no log do PostgreSQL?

Qual o SO, x64?

Você pode descrever melhor como que é esse processo de destravar pelo 
pgAdmin?


Grato



-- 


___
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 mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Forma de resolver um travamento

2016-12-14 Por tôpico Cleiton Luiz Domazak
2016-12-14 14:37 GMT-02:00 Leonardo Coleraus :

> Boa Tarde Amigos,
>
> Estou tendo um problema aqui na empresa, o que acontece.
>
> Os Caixa ao emitir as NF-e Danfe, dependendo o momento do dia acontece um
> travamento no banco, onde hoje vou la no PGAdmin e destravo manualmente,
> mas  quero ajuda de vocês* pra saber qual a melhor forma de saber porque
> esse travamento por onde posso começar a diagnosticar pra poder ser
> resolvido esse problema* que esta ocasionando bastante problema, pois não
> SO trava os Caixa e sim toda a empresa.
>
> Usamos o PostgreSQL 9.3 com o ERP Adempiere com 190 conexões
>
O que aparece no log do PostgreSQL?

Qual o SO, x64?

Você pode descrever melhor como que é esse processo de destravar pelo
pgAdmin?


> Grato
>
>
>
> --
>
> ___
> 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] Forma de resolver um travamento

2016-12-14 Por tôpico Leonardo Coleraus

Boa Tarde Amigos,

Estou tendo um problema aqui na empresa, o que acontece.

Os Caixa ao emitir as NF-e Danfe, dependendo o momento do dia acontece 
um travamento no banco, onde hoje vou la no PGAdmin e destravo 
manualmente, mas  quero ajuda de vocês*pra saber qual a melhor forma de 
saber porque esse travamento por onde posso começar a diagnosticar pra 
poder ser resolvido esse problema* que esta ocasionando bastante 
problema, pois não SO trava os Caixa e sim toda a empresa.


Usamos o PostgreSQL 9.3 com o ERP Adempiere com 190 conexões

Grato



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

[pgbr-geral] Instalação do PostgreSQL em Mac

2016-12-14 Por tôpico Danilo Silva
Pessoal,

Vocês teriam um tutorial de instalação do postgres no mac (versão yosemite)?

Qual a melhor forma de instalar?

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