from:"Jean"

Então, estranho esse comportamento.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Emerson da Silva Chalegre" <emerchale...@gmail.com>Em: Quarta-feira 23 de Dezembro de 2015 17:13,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Problema com campo numericEm funcões e triggers de vez em quando tenho problema parecido, e com isso pego o valor e multiplico 1..Tente assim, pode ser que resolva.(0.2523*1.)Em 23 de dezembro de 2015 16:42, Glauco Torres <torres.gla...@gmail.com> escreveu:No dia 23 de dezembro de 2015 às 16:12, Jean - GECONTROL <j...@gecontrolsistemas.com.br> escreveu:Esses dias eu tive problema num cliente, que tentava editar um registro, e colocar num campo numeric(18,4) o valor 0.2523. Tentei pela aplicação, e depois direto, pelo PgManager, e o campo não aceitava o valor, que ficava 0.2520. Olhar na trigger, e única referencia ao campo era um campo = coalesce(campo,0). Editei o valor para 0.2524 e aceitou. Ai tenteni novamente por o valor 0.2523, e ai aceitou. Não sei dizer o que houve. A versão do Pg é 9.3.10 64 bits rodando no Windows Server 2008 R2.Alguém já teve algum problema parecido? Eu, não :|Qual era o retorno que você tinha? numeric no PgManager não é . (ponto) é , (virgula) será que não era isso?-Glauco Torres 

___
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-geral@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

Re: [pgbr-geral] Problema com campo numeric

Eu editei no grid. Mas é estranho o comportamento, tanto na aplicação como no grid. Não testei executando uma instrução SQL.De: "Glauco Torres" <torres.gla...@gmail.com>Em: Quarta-feira 23 de Dezembro de 2015 16:42,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Problema com campo numericNo dia 23 de dezembro de 2015 às 16:12, Jean - GECONTROL <j...@gecontrolsistemas.com.br> escreveu:Esses dias eu tive problema num cliente, que tentava editar um registro, e colocar num campo numeric(18,4) o valor 0.2523. Tentei pela aplicação, e depois direto, pelo PgManager, e o campo não aceitava o valor, que ficava 0.2520. Olhar na trigger, e única referencia ao campo era um campo = coalesce(campo,0). Editei o valor para 0.2524 e aceitou. Ai tenteni novamente por o valor 0.2523, e ai aceitou. Não sei dizer o que houve. A versão do Pg é 9.3.10 64 bits rodando no Windows Server 2008 R2.Alguém já teve algum problema parecido? Eu, não :|Qual era o retorno que você tinha? numeric no PgManager não é . (ponto) é , (virgula) será que não era isso?-Glauco Torres 

___pgbr-geral mailing listpgbr-geral@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] Dúvida sobre postgres_fdw

Pessoal, alguém sabe dizer se é possível executar uma query diretamente num banco de dados externo, sem ter que criar uma foreign table, usando postgres_fdw?Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre postgres_fdw

Preferia evitar. É uma pena. Valeu.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Rafael Fialho" <rafafial...@gmail.com>Em: Terça-feira 05 de Janeiro de 2016 15:45,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Dúvida sobre postgres_fdwEm 5 de janeiro de 2016 15:41, Jean - GECONTROL <j...@gecontrolsistemas.com.br> escreveu:Pessoal, alguém sabe dizer se é possível executar uma query diretamente num banco de dados externo, sem ter que criar uma foreign table, usando postgres_fdw?Caso seja uma possibilidade, poderia utilizar dblink.[]'s 
___pgbr-geral mailing listpgbr-geral@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

Re: [pgbr-geral] Dúvida sobre postgres_fdw

Que pena.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Flavio Henrique Araque Gurgel" Em: Terça-feira 05 de Janeiro de 2016 15:43,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Dúvida sobre postgres_fdw> Pessoal, alguém sabe dizer se é possível executar uma query diretamente> num banco de dados externo, sem ter que criar uma foreign table, usando> postgres_fdw?Não.[]sFlavio Gurgel___pgbr-geral mailing listpgbr-geral@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

Re: [pgbr-geral] Problema com campo numeric

Entao... certeza... numeric(18,4).Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Matheus de Oliveira" <matioli.math...@gmail.com>Em: Quinta-feira 24 de Dezembro de 2015 12:57,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Problema com campo numeric2015-12-23 17:12 GMT-02:00 Emerson da Silva Chalegre <emerchale...@gmail.com>:Em funcões e triggers de vez em quando tenho problema parecido, e com isso pego o valor e multiplico 1..Tente assim, pode ser que resolva.(0.2523*1.)Isso não era pra acontecer se você estiver usando apenas tipo NUMERIC, tem certeza que não tem nenhum double precision ou real (a.k.a. float8 e float4) envolvidos nessas operações? (a mesma pergunta vale para o OP).Atenciosamente,-- Matheus de Oliveira

___pgbr-geral mailing listpgbr-geral@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

Re: [pgbr-geral] Dúvida sobre postgres_fdw

De: "Flavio Henrique Araque Gurgel"  
Em: Terça-feira 05 de Janeiro de 2016 15:50, 

Para: pgbr-geral@listas.postgresql.org.br
Assunto: Re: [pgbr-geral] Dúvida sobre postgres_fdw



> Que pena.

Evite o top-posting, bagunça a lista.

>  > Pessoal, alguém sabe dizer se é possível executar uma query diretamente
>  > num banco de dados externo, sem ter que criar uma foreign table, usando
>  > postgres_fdw?

Se você explicar sua necessidade talvez possamos ajudá-lo melhor.
O que te impede de criar uma tabela estrangeira? Não vejo porque isso 
possa ser uma restrição.

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


É que preciso chamar o resultado de uma função que retorna registros em outra 
base, e não uma tabela específica.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Problema com campo numeric

2015-12-23 Por tôpico Jean - GECONTROL

Esses dias eu tive problema num cliente, que tentava editar um registro, e colocar num campo numeric(18,4) o valor 0.2523. Tentei pela aplicação, e depois direto, pelo PgManager, e o campo não aceitava o valor, que ficava 0.2520. Olhar na trigger, e única referencia ao campo era um campo = coalesce(campo,0). Editei o valor para 0.2524 e aceitou. Ai tenteni novamente por o valor 0.2523, e ai aceitou. Não sei dizer o que houve. A versão do Pg é 9.3.10 64 bits rodando no Windows Server 2008 R2.Alguém já teve algum problema parecido?Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] could not send data to client: Conexão fechada pela outra ponta

2015-11-04 Por tôpico Jean - GECONTROL

Tenho esse problema num cliente, e a culpa é do F-Secure... não consegui resolver com exceções.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Flavio Henrique Araque Gurgel" Em: Terça-feira 03 de Novembro de 2015 11:42,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] could not send data to client: Conexão fechada pela outra ponta> Acredito mais na hipótese de que algo entre aplicação de banco tenha> derrubado a conexão, firewall, antivírus, talvez IPV6 (pesquisando vi> posts em java+postgresql falando nesse assunto) ou algo assim. Pois> não são todas as máquinas que perdem a conexão, de 20 estações umas> 3,4 apresentam esse problema.Verifique os endereços MAC das placas de rede dessas 3, 4 máquinas e veja se não há conflito.Era comum uma época comprarmos placas OEM e elas terem... MAC iguais.Tente também fazer arping na sua rede e verificar se duas máquinas não respondem juntas.[]sFlavio Gurgel___pgbr-geral mailing listpgbr-geral@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

Re: [pgbr-geral] Timeout Conexão

2015-03-25 Por tôpico Jean - GeControl

Já vi esse erro também, e era problema com o antivírus, no caso, o F-Secure.Jean DominguesSócio-ProprietárioGecontrol Consultoria e Sistemas.De: "Douglas Fabiano Specht" douglasfabi...@gmail.comEm: Segunda-feira 23 de Março de 2015 14:56,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Timeout ConexãoEm 23 de março de 2015 14:32, Mauro Fonseca mfons...@pbh.gov.br escreveu:Tive algumas experiências com esta mensagem e geralmente era erro falha na rede do usuário.Em 23 de março de 2015 14:01, Pedro B. Alves pedroalve...@gmail.com escreveu:Qual erro é apresentado? Algo nos logs do servidor também?Nos logs não tem nada.
___
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
Amigo,deixe um ping -t para o ip do servidor e veja se nao vai cair a conexao neste momento da mensagem.-- Douglas Fabiano Specht

___pgbr-geral mailing listpgbr-geral@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

Re: [pgbr-geral] Replicação postgres



On 02/10/2015 11:58 AM, Flavio Henrique Araque Gurgel wrote:

On 02/10/2015 09:35 AM, Leandro wrote:

Pessoal, utilizo a replicação sincrona do postgresql  versão 9.2 e
depois de um tempo em execução a mesma apresentou problemas na replica
conforme logs abaixo:

WARNING,01000,page 1186 of relation base/91198868/91199917 is
uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk
1201, lastBlockVacuumed 0
PANIC,XX000,WAL contains references to invalid pages,xlog redo
vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 
0


sendo que o master da replicação parece estar tudo normal,
alguem já passou por situação parecida?


Qual a versão exata? É a última da série 9.2?
Há um bug conhecido e, dependendo da sua versão, pode não estar 
corrigido.

A ordem é:
1) atualize os binários do PostgreSQL para 9.2.10 (no seu caso)
2) refaça o escravo (novo pg_basebackup).


Hoje as 9:50 começou este problema para mim, estou procurando uma
alternativa também.
Versão 9.3.6


Não é a mesma versão do outro colega. Mas refaça seu pg_basebackup e 
recrie o novo escravo.
Embora sua versão esteja em dia, se o pg_basebackup foi feito com a 
versão bugada, o erro pode acontecer tardiamente.

Isso eu não sabia, talvez seja essa minha situação então.




2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING: page 196
of relation base/26790/24953388 is uninitialized
2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT: xlog redo
visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC:  WAL
contains references to invalid pages
2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT: xlog redo
visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG: startup
process (PID 4882) was terminated by signal 6: Aborted
2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating
any other active server processes


como posso verificar que objeto que está apresentando o problema?


Outra pergunta, abra outro assunto, não sequestre.
Você encontra todos os objetos na tabela pg_class, no seu caso filtre 
pelo relfilenode :

SELECT relname FROM pg_class WHERE relfilenode = 24953388;

A consulta vai te retornar o nome da tabela ou índice corrompido.

[]s
Flavio Gurgel
___
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] Replicação postgres



On 02/10/2015 12:08 PM, Flavio Henrique Araque Gurgel wrote:

Fiz um backup da base no slave, e fiz uma copia do arquivo que
apresentava erro, ou seja, copiei ele do master pro slave e dei start. A
principio está funcionando... vou monitorar o mesmo, qualquer coisa
também eu volto o bkp.


Isso é um perigo enorme e você pode ter inconsistências no escravo.
Refazer o escravo do zero é o mais seguro.


Sim, mas por isso mesmo eu fiz um backup do escravo antes.
Estou verificando a situação, já que esse escravo está distante e vai 
depender do link para refazer o mesmo, e também ele é a ultima da ultima 
instancia.

Ele faz parte da redundancia de DC, e eu tenho mais um slave aqui.

[]s
Flavio Gurgel
___
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] Replicação postgres



On 02/10/2015 10:51 AM, Jean Pereira wrote:

On 02/10/2015 09:35 AM, Leandro wrote:
Pessoal, utilizo a replicação sincrona do postgresql  versão 9.2 e 
depois de um tempo em execução a mesma apresentou problemas na 
replica conforme logs abaixo:


WARNING,01000,page 1186 of relation base/91198868/91199917 is 
uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 
1201, lastBlockVacuumed 0
PANIC,XX000,WAL contains references to invalid pages,xlog redo 
vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0


sendo que o master da replicação parece estar tudo normal,
alguem já passou por situação parecida?

Hoje as 9:50 começou este problema para mim, estou procurando uma 
alternativa também.

Versão 9.3.6

2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING:  page
196 of relation base/26790/24953388 is uninitialized
2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT:  xlog
redo visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC:  WAL
contains references to invalid pages
2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT:  xlog
redo visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG:  startup
process (PID 4882) was terminated by signal 6: Aborted
2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating
any other active server processes

Fiz um backup da base no slave, e fiz uma copia do arquivo que 
apresentava erro, ou seja, copiei ele do master pro slave e dei start. A 
principio está funcionando... vou monitorar o mesmo, qualquer coisa 
também eu volto o bkp.



como posso verificar que objeto que está apresentando o problema?


___
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] Replicação postgres


On 02/10/2015 09:35 AM, Leandro wrote:
Pessoal, utilizo a replicação sincrona do postgresql  versão 9.2 e 
depois de um tempo em execução a mesma apresentou problemas na replica 
conforme logs abaixo:


WARNING,01000,page 1186 of relation base/91198868/91199917 is 
uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 
1201, lastBlockVacuumed 0
PANIC,XX000,WAL contains references to invalid pages,xlog redo 
vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0


sendo que o master da replicação parece estar tudo normal,
alguem já passou por situação parecida?

Hoje as 9:50 começou este problema para mim, estou procurando uma 
alternativa também.

Versão 9.3.6

   2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING:  page 196
   of relation base/26790/24953388 is uninitialized
   2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT:  xlog redo
   visible: rel 1663/26790/24953388; blk 196
   2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC:  WAL
   contains references to invalid pages
   2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT:  xlog redo
   visible: rel 1663/26790/24953388; blk 196
   2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG:  startup
   process (PID 4882) was terminated by signal 6: Aborted
   2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG:  terminating
   any other active server processes


como posso verificar que objeto que está apresentando o problema?


___
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] Configurar acessos no arquivos pg_hba.conf

2015-01-28 Por tôpico Jean - GeControl

Crie mais que uma linha no pg_hba.conf.Jean DominguesSócio-ProprietárioGecontrol Consultoria e Sistemas.De: "Matheus Saraiva" matheus.sara...@gmail.comEm: Terça-feira 27 de Janeiro de 2015 11:17,  Para: pgbr-geral@listas.postgresql.org.brAssunto: [pgbr-geral] Configurar acessos no arquivos pg_hba.confBem, eu configurei o pg_hba.conf para liberar o acesso apenas para umip, [IP]/32, porém, eu quero também liberar o acesso via localhost. Comofazer?___pgbr-geral mailing listpgbr-geral@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

Re: [pgbr-geral] Informação sobre conversão de tipo automática.

2014-12-18 Por tôpico Jean Pereira



On 12/17/2014 06:08 PM, Matheus de Oliveira wrote:


2014-12-17 14:35 GMT-02:00 Jean Pereira ad...@olostech.com 
mailto:ad...@olostech.com:


CREATE TEMP table table_a (field_a time);

Efetuo a inserção de um dado, sendo que utilizo o
current_timestamp, e o banco efetua a conversão automática para
time na hora que insere.

insert into table_a values (current_timestamp);

Mas se eu efetuo um simples select utilizando tambem o
current_timestamp

select * from table_a where field_a = current_timestamp;


Bem, existe uma diferença básica. Só para exemplificar o conceito, no 
PostgreSQL as conversões de tipos são tratadas por funções, sendo que 
existe três tipos de conversões:


- explícitas: são aquelas que você deixa claro, exemplo: 
CAST(current_timestamp AS time) ou current_timestamp::time
- implícitas: (em inglês chamados de implicit casts) são aqueles 
literalmente implícitos, por exemplo a conversão de int para 
bigint, um int sempre cabe num bigint, logo essa conversão pode 
ser feita sem perda alguma, *SEMPRE*
- implícitas no assinalamento: (em inglês assignment casts) são 
usadas em operações de atribuição, por exemplo, num INSERT, num UPDATE 
ou ALTER TABLE ... ALTER ... TYPE (na verdade só conheço esses três, 
não sei se tem mais).


Sabendo disso fica fácil identificar o seu caso. No INSERT o 
PostgreSQL irá procurar por um implict cast ou assignment cast de 
timestamptz para time, existindo (e existe) este será usado. Já no 
SELECT o PostgreSQL irá procurar primeiro por um operador de igualdade 
entre os dois tipos em questão, se este não existir (e não existe) aí 
sim ele irá procurar por um implicit cast, que no caso também não 
existe, logo o erro (não tenho certeza se a ordem é essa operador 
depois cast, mas creio que seja).


Só pra deixar documentado, se for no psql e executar `\dC 'timestamp 
with time zone'` irá obter:


postgres=# \dC 'timestamp with time zone'
  List of casts
 Source type | Target type |  
Function   |   Implicit?

-+-+-+---
 abstime | timestamp with time zone| 
timestamptz | yes
 date| timestamp with time zone| 
timestamptz | yes
 timestamp without time zone | timestamp with time zone| 
timestamptz | yes
 timestamp with time zone| abstime | 
abstime | in assignment
 timestamp with time zone| date| 
date| in assignment
 timestamp with time zone| timestamp without time zone | 
timestamp   | in assignment
 timestamp with time zone| timestamp with time zone| 
timestamptz | yes
 timestamp with time zone| time without time zone  | 
time| in assignment
 timestamp with time zone| time with time zone | 
timetz  | in assignment

(9 rows)

A última linha é o cast que foi usado no seu comando INSERT. 
Resumindo, os hackers do PostgreSQL acharam que seria razoável a 
conversão de timestamptz para time de forma implícita, mas somente 
numa atribuição.


Espero que tenha esclarecido.


Beleza, obrigado pelas informações.

Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres http://www.dextra.com.br/postgres/



___
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] Informação sobre conversão de tipo automática.

2014-12-17 Por tôpico Jean Pereira


Pessoal, gostaria de saber se isto é um bug ou é algo normal

Crio a tabela

   CREATE TEMP table table_a (field_a time);

Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o 
banco efetua a conversão automática para time na hora que insere.


   insert into table_a values (current_timestamp);

Mas se eu efetuo um simples select utilizando tambem o current_timestamp

   select * from table_a where field_a = current_timestamp;
   ERROR:  operator does not exist: time without time zone = timestamp
   with time zone
   LINE 1: select * from table_a where field_a = current_timestamp;
^
   HINT:  No operator matches the given name and argument type(s). You
   might need to add explicit type casts.


Sei que eu deveria efetuar a comparação com time, mais detectamos tal 
situação, aonde um campo que era para ser timestamp está como time, e as 
gravações ocorreram normalmente, aonde eu acredito que não deveriam 
acontecer também como no select.
O campo é de uma tabela de log, praticamente não utilizado e por isso 
não percebemos o erro.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Informação sobre conversão de tipo automática.

2014-12-17 Por tôpico Jean Pereira



On 12/17/2014 02:42 PM, Flavio Henrique Araque Gurgel wrote:

Pessoal, gostaria de saber se isto é um bug ou é algo normal

Crio a tabela

CREATE TEMP table table_a (field_a time);

Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o
banco efetua a conversão automática para time na hora que insere.

insert into table_a values (current_timestamp);

Mas se eu efetuo um simples select utilizando tambem o current_timestamp

select * from table_a where field_a = current_timestamp;
ERROR:  operator does not exist: time without time zone = timestamp
with time zone
LINE 1: select * from table_a where field_a = current_timestamp;
 ^
HINT:  No operator matches the given name and argument type(s). You
might need to add explicit type casts.


É normal.
A conversão de timestamp para hora é trivial e está na tabela de 
conversões de tipos, mas o contrário não e não vale para comparações. 
Note que isso poderia te levar a erro grave de semântica.



Sei que eu deveria efetuar a comparação com time, mais detectamos tal
situação, aonde um campo que era para ser timestamp está como time, e as
gravações ocorreram normalmente, aonde eu acredito que não deveriam
acontecer também como no select.
O campo é de uma tabela de log, praticamente não utilizado e por isso
não percebemos o erro.


Simplesmente inclua a conversão no seu SELECT:
select * from table_a where field_a = current_timestamp::time;

Ou use outra função, a current_time:
select * from table_a where field_a = current_time;


Beleza, sobre a conversão tudo bem, eu só achei estranho tal situação.

[]s
Flavio Gurgel
___
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] Backup | Restore | PITR

2014-10-28 Por tôpico Jean Pereira


Bom dia,

Sugiro a leitura do livro Instant PostgreSQL Backup and Restore 
How-to, gostei muito do mesmo, e além do que já foi recomendado aqui na 
lista também.



On 10/28/2014 08:44 AM, Fernando Cambiaghi wrote:

Bom dia Pessoal,

Sou novo na lista, tenho acompanhado alguns emails e fico 
impressionado com a dedicação do pessoal em responder a todas as 
questões com o nível incrível de detalhe. Parabéns.


Fiz um curso na Dextra em SP a uns dois anos, e estou trabalhando para 
migrar um banco de dado X para PostgreSQL. ( Estou utilizando 
windows 7 com versão 9.3.5 do PostgreSQL.


O tamanho da minha base de dados é relativamente pequena ( 231 tabelas 
ocupando um total entre 4GB e 5GB ).


Pois bem, a migração do bando está feita ( Homologando ), e agora 
estou me apegando a entender a parte de Backup e Restore, mas estou 
tendo muita dificuldade, mas creio que por falta de entendimento meu.


No meu ambiente atual, faço backup completo do banco de dados todas as 
noites, com o banco online e em uso, e tenho o log de transações para, 
em caso de catástrofe*, posso pegar o último backup completo e aplicar 
o log atual ( Tem todo um processo de transcrever e ler o mesmo para o 
banco ).



Com o PostgreSQL, entendi que para ter um ambiente igual, para em caso 
de catástrofe poder recuperar os dados para o mais atual possível, eu 
devo efetuar um backup completo diariamente ( estou fazendo isso com o 
pg_dump ) e manter os archives ativados [1]. Até aí creio que fiz tudo 
certo.


Para simular uma catástrofe, eu desligo o computador com transações 
ocorrendo no banco, e quando ligo novamente, não consigo nem subir o 
serviço do postgres, aí é que começo a apanhar.


Desinstalo e reinstalo o postgres, mesma versão, volto o backup 
(pg_restore) e sigo as instruções de [1], mas não consigo. Quando digo 
não consigo, é estou fazendo algo errado, não volta os archives.


Gostaria de saber se alguém tem um passo a passo mais detalhado de 
como fazer isso, pois não quero colocar o banco postgres em produção 
sem ter domínio de como restaurar um backup em caso de problemas.


[1] http://www.postgresql.org/docs/9.3/static/continuous-archiving.html

*Qualquer tipo de perda de dados ou do próprio banco de dados.

Perdoem por me alongar tanto, mas queria apresentar minha situação e 
apresentação ao grupo.


Agradeço a todos pela compreensão.

Fernando Luís Cambiaghi
/cambia...@gmail.com mailto:cambia...@gmail.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] Aprender mais sobre PostgreSQL

2014-09-03 Por tôpico Jean Pereira

Aqui (http://www.postgresql.org/docs/books/) você pode ver alguns dos 
livros sobre PostgreSQL.


On 09/02/2014 09:09 PM, Roger Eduardo wrote:

Eu também já pensei em perguntar isso de forma mais ampla.
Quais são os livros que vocês leram e recomendam sobre Postgresql?

Att,

Roger Eduardo.
+55 11 973 222 198


2014-09-02 20:07 GMT-03:00 Fabio Romanzini fabioromanzin...@gmail.com 
mailto:fabioromanzin...@gmail.com:


Boa noite Pessoal,

Estou mexendo com o PostgreSQL faz 4 anos já, porém estou sempre a
procura de aprender mais sobre o Postgres, gostaria de saber se
alguém sabe ou possui algum documento que possa ser compartilhado
para estudar?


-- 
/*Fabio Romanzini*/


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
mailto: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] Case com Zebedee

2014-07-28 Por tôpico Jean - GeControl

Boa tarde Jean,

Em 25-07-2014 08:32, Jean - GeControl
escreveu:

.x_notviscode, .notviscode { visibility: hidden; width: 0px; height: 0px; display: none; }
Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel
entre
o server e o client e toda informação que trafega neste
tunel é
compactada, deixando assim a comunicação entre
cliente/servidor mais
rápida.

Uma pergunta de leigo: qual a diferença, em termos de
performance, entre
uma ferramenta deste segmento e um túnel VPN sobre UDP
compactado, como
por exemplo, o OpenVPN?

Tá aí, realmente não sei. Quem usa podia por aqui o case, sobre
a diferença de performance, assim como Postgresql com SSL. O
zebedee é muito leve, e no meu caso, não usei criptografia. Mas
acredito que outras soluções do gênero ofereçam o mesmo
benefício.

Aproveitei alguns minutos do almoço e fiz uma avaliação rápida
cruzando acesso direto e VPN com e sem SSL. Utilizei o seguinte
cenário:

Consulta que me retorna 1.642 registros com aprox. 2MB de
tráfego de texto plano;

O servidor encontra-se a 30 saltos (via traceroute) de onde
estou no momento. Executei os comandos em uma maquina linux com
conexão ADSL GVT;
Como estamos em um horário de produção e a ADSL nesses horário
pode ser afetada, a repetição do comando gerou alguns dados com
distorções significativas. então capturei o valor mais próximo
entre eles de um total de 10 execuções com intervalo de 2
segundos entre as execuções;
A consulta executada em localhost no servidor do banco tem um
tempo de 10.998 ms;
Para não considerar o tempo de autenticação e validação da
senha, seja manual, por software ou via .pgpass, alterei os
acessos do usuário para TRUST para os IPs utilizados (público de
minha estação e da VPN).

##Execução com IP público

#PSQL COM SSL habilitado
$ export SSLMODE=required
$ time psql portal -U daniel -h IP -c "select * from
tb_pedidos where fk_cliente = id" /dev/null

real 0m1.823s
user 0m0.089s
sys 0m0.009s

#PSQL SEM SSL habilitado
$ export SSLMODE=disable
$ time psql portal -U daniel -h IP -c "select * from
tb_pedidos where fk_cliente = id" /dev/null

real 0m2.072s
user 0m0.090s
sys 0m0.012s

##Execução em VPN com comp-lzo habilitado

#PSQL COM SSL habilitado
$ export SSLMODE=required
$ time psql portal -U daniel -h 10.1.0.10 -c "select * from
tb_pedidos where fk_cliente = id" /dev/null

real 0m1.861s
user 0m0.090s
sys 0m0.010s

##PSQL SEM SSL habilitado

$ export SSLMODE=disable
$ time psql portal -U daniel -h 10.1.0.10 -c "select * from
tb_pedidos where fk_cliente = id" /dev/null

real 0m1.785s
user 0m0.086s
sys 0m0.013s

Uma vez que o OpenVPN já é criptografado e esta com compactação
habilitada, a melhor situação foi VPN com conexão ao banco SEM SSL.
Apesar da diferença ser muito baixa.

Espero que ajude.

Att,
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDADaniel... creio que o mais importante nesses teste de tráfego seja o fetch time, ou seja, o tempo que demora para o dadotrafegar para o lado client. O tempo de execução está relacionado a cache de dados. Não entendi se você levou isso em conta noteste acima.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Case com Zebedee

2014-07-25 Por tôpico Jean - GeControl

 Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre  o server e o client e toda informação que trafega neste tunel é  compactada, deixando assim a comunicação entre cliente/servidor mais  rápida.Uma pergunta de leigo: qual a diferença, em termos de performance, entre uma ferramenta deste segmento e um túnel VPN sobre UDP compactado, como por exemplo, o OpenVPN?Tá aí, realmente não sei. Quem usa podia por aqui o case, sobre a diferença de performance, assim como Postgresql com SSL. O zebedee é muito leve, e no meu caso, não usei criptografia. Mas acredito que outras soluções do gênero ofereçam o mesmo benefício.Jean Domingues - GECONTROL___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Case com Zebedee

2014-07-23 Por tôpico Jean - GeControl

Pessoal,apenas compartilhando com a lista: estou acessando o banco de dados Postgresql através da internet, através de um link dedicado de 2Mbps do lado host e client. Pra melhorar o desempenho, coloquei o Zebedee pra fazer o tunneling, com compactação de pacotes. Percebi que a melhor no Fetch das consultas ficou na casa dos 65%, em média. Visivelmente, no manuseio do sistema ERP, o ganho foi considerável.Espero que o case sirva pra outros usuários.Jean DominguesSócio-ProprietárioGecontrol Consultoria e Sistemas.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Opinião - Amazon

2014-06-27 Por tôpico Jean Pereira


Boa tarde,

Gostaria de uma opinião de vocês.

Temos um sistema que gerencia a saúde publica de alguns municípios do 
pais, atende a +- 2 milhões de pessoas. Roda 24/7 em todos os postos de 
saúde, UPA 24 e pronto socorros de alguns clientes. O sistema em si já 
ultrapassa as 9 milhões de transações dia.


Situação é a seguinte, hoje tenho uma estrutura redundante, de 
datacenter e servidores, e no qual tenho um gasto de +- R$ 6500,00 (+ a 
depreciação) - contando tudo. Sendo a estrutura master com redundância 
aqui na empresa, e mais uma redundância em outro DC.


Nessa situação, eu estou sendo questionado sobre a amazon, mais por 
causa do custo, sendo que eles na teoria fornecem tudo redundante e com 
SLA de 99.95% ao mês (se não me engano), que na teoria também o custo é 
menor.


Hoje minha SLA dos servidores está em 99.997% e do BGP em 99.96%

Gostaria da opinião de quem usa, ou de quem já usou, ou até mesmo de 
quem trabalha com situação parecida de disponibilidade.

Os contratos são com SLA, e alta demanda, e para piorar, sem fidelidade.


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

Re: [pgbr-geral] Opinião - Amazon

2014-06-27 Por tôpico Jean Pereira



On 06/27/2014 02:00 PM, Flávio Granato wrote:

On 06/27/2014 01:53 PM, Jean Pereira wrote:

Boa tarde,

Gostaria de uma opinião de vocês.

Temos um sistema que gerencia a saúde publica de alguns municípios do
pais, atende a +- 2 milhões de pessoas. Roda 24/7 em todos os postos
de saúde, UPA 24 e pronto socorros de alguns clientes. O sistema em si
já ultrapassa as 9 milhões de transações dia.

Situação é a seguinte, hoje tenho uma estrutura redundante, de
datacenter e servidores, e no qual tenho um gasto de +- R$ 6500,00 (+
a depreciação) - contando tudo. Sendo a estrutura master com
redundância aqui na empresa, e mais uma redundância em outro DC.

Nessa situação, eu estou sendo questionado sobre a amazon, mais por
causa do custo, sendo que eles na teoria fornecem tudo redundante e
com SLA de 99.95% ao mês (se não me engano), que na teoria também o
custo é menor.

Hoje minha SLA dos servidores está em 99.997% e do BGP em 99.96%

Gostaria da opinião de quem usa, ou de quem já usou, ou até mesmo de
quem trabalha com situação parecida de disponibilidade.
Os contratos são com SLA, e alta demanda, e para piorar, sem
fidelidade.

Uma sugestão que acho importantíssimo você ter uma definição é sobre o
local de armazenamento dos dados. Um professor meu comentou que um
serviço de proteção ao crédito utiliza infra virtualizada por uma dessas
grandes mas a justiça brasileira orientou a deixar os dados no Brasil
por questões jurídicas.

Sim, mais na teoria, eles tem em SP não?
Essa questão para mim é primordial, já que são prontuários de pacientes 
(por exemplo), que em processos (que não são poucos, ainda mais contra a 
saúde pública) são requeridos/utilizados, etc..


___
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] pg_basebackup para fita

2014-02-06 Por tôpico Jean Pereira




On 02/05/2014 04:28 PM, Flavio Henrique Araque Gurgel wrote:



 Gostaria de saber se é viável e se tem como eu rodar um 
pg_basebackup e mandar direto para a fita (/dev/st0)?


Sim sem problemas.
O único inconveniente que vejo é que isso demora dependendo do 
tamanho, mas aí é caso a caso.



Legal.. é somente 120 Gb, pequeno ainda.
Hoje efetuo o backup e depois mando para a fita.
Posso estar enganado, mais acho que mandar direto fica mais rápido. É LTO-3

Flavio, eu não sei exatamente o comando, e também não achei tal exemplo 
na internet, poderia me ajudar com o mesmo?


Obrigado.


[] s



___
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] pg_basebackup para fita

2014-02-06 Por tôpico Jean Pereira



On 02/05/2014 04:52 PM, Douglas Fabiano Specht wrote:




Em 5 de fevereiro de 2014 16:28, Flavio Henrique Araque Gurgel 
fha...@gmail.com mailto:fha...@gmail.com escreveu:



 Gostaria de saber se é viável e se tem como eu rodar um
pg_basebackup e mandar direto para a fita (/dev/st0)?

Sim sem problemas.
O único inconveniente que vejo é que isso demora dependendo do
tamanho, mas aí é caso a caso.

[] s


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


nao seria melhor vc colocar para fazer o bckup um uma partição do 
disco, e ter um shell script que copie ele para a fita?

Praticamente faço isso hoje.


--

Douglas Fabiano Specht


___
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_basebackup para fita

2014-02-05 Por tôpico Jean Pereira


Boa tarde,

Gostaria de saber se é viável e se tem como eu rodar um pg_basebackup e 
mandar direto para a fita (/dev/st0)?


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

Re: [pgbr-geral] Replicação

2013-12-02 Por tôpico Jean Vichinheski

Essa empresa tem a solução certa pra vc homologada e funciona 100 %
http://www.psmi.com.br/ fala com o Cesar Antonio dos Santos  Eles tem o
Beehive Replicator ! Faz a replicação de banco de dados mantendo uma
matriz e varias filiais com bastante recursos!!!


att,

JEan


Em 2 de dezembro de 2013 16:19, Daviramos Roussenq Fortunato 
daviramo...@gmail.com escreveu:

 Olá Lista,

   Sou novo por aqui, mas já trabalho a uns 5 anos com Postgresql, já
 pesquisei bastante sobre meu problema, mas ainda não consegui chega a uma
 solução. Vou tentar explicar brevemente o que preciso, e espero que os
 Colaboradores da Lista, possam contribuir meu caso.

Tenho uma Matriz + 4 Filiais, hoje o Banco roda apenas na Matriz e as
 filiais acessam a Matriz via Terminal Service. A filiais ficam em lugares
 distantes sem grande recursos de Internet.

Gostaria de instalar o Banco na Filiais que serviria para executar as
 consultas, e os Inserts fossem enviados para o Banco da Matriz, e o Banco
 da Matriz se atualizaria as filiais.

 Não posso fazer isso na APLICAÇÃO, eu preciso que o próprio SGDB
 consiga tratar. Alguém teria uma dica?

 --
 Atenciosamente
 Daviramos Roussenq Fortunato

 ___
 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] PANIC: right sibling's left-link doesn't match

2013-09-27 Por tôpico Jean Pereira


On 09/26/2013 07:57 PM, Matheus de Oliveira wrote:




2013/9/26 Adriano Espinoza de Oliveira adrianoespin...@gmail.com 
mailto:adrianoespin...@gmail.com


Boa tarde pessoal.


Boa noite... =D


Hje de manhã tivemos too many clients no banco, eu não esta na
empresa, e o adm de redes foi lá e derrubou um monte de conexões
do postgres que ele achou q eram antigas...


Bom, a alguns anos atrás, fiz isso também, se não me engano também era 
na versão 8.x (não lembro exato porque faz tempo, talvez seja a 7.x).


Derrubou como? Se foi um kill -9 é bom dar um kill -9  `pidof 
cara_que_fez_isso`... =P



Estou brincando viu, vamos lá ...

O banco ficou inacessível, ele fez um restart do banco, que não
subiu. Teve que apagar o PID na unha e depois o banco subiu...


Ok. Normal...


Depois disso, quando cheguei, notei que o banco estava se
derrubando e subindo sozinho, exibindo essas mensagens:

* 2013-09-26 12:09:25 BRT [18539]: [1-1] db=,user= LOG:  server
process (PID 23040) was terminated by signal 6*
* 2013-09-26 12:09:25 BRT [18539]: [2-1] db=,user= LOG:
 terminating any other active server processes*
*10.11.0.2 2013-09-26 12:09:25 BRT [23043]: [3-1]
db=cimed,user=postgres WARNING:  terminating connection because of
crash of another server process*
*(...)*


E tive um problema muito parecido... como falei, não consigo precisar, 
faz muito tempo...
A solução que eu tive foi que achei um script em um post falando do 
problema e que o mesmo resolveria isso, olhei o script e rodei o mesmo. 
resolveu o meu problema.


Como um velho conhecido meu fala, o kill é o ultimo do ultimo caso. Já 
que você deve ter conexões reservadas ao postgres, e o mesmo consegue 
matar conexão por dentro do banco.


Mais não é o caso agora... vou tentar achar aqui a situação que tive e a 
solução exata, se eu achar eu posto.


Essas mensagens querem dizer que  um dos backends do PostgreSQL 
terminou e os demais pararam também pelo fato deste poder ter 
corrompido a memória compartilhada.




Quando subia, esse era o log:

*(...)*

e sempre precedido dessas msg´s ( note que tive varias ocorrencias
dela)

*10.11.0.2 2013-09-26 12:09:24 BRT [23040]: [3-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*(...)*
*10.11.0.2 2013-09-26 15:05:46 BRT [3063]: [15-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*
*


Ok. Aqui parece que temos o problema: algum(ns) índice(s) corrompido(s)...


*além da informação de roll back das transações: *
*
10.11.0.2 2013-09-26 17:25:11 BRT [11831]: [4-1]
db=nutracom,user=visao DETAIL:  The postmaster has commanded this
server process to roll back the current transaction and exit,
because another server process exited abnormally and possibly
corrupted shared memory.
(...)

*

Normal...


Pesquisando, vi que poderia ser corrupção de indices...

Derrubei o banco, limitei o acesso dos usuários, e executei o
reindex de todas as tabelas em lote, com script.


Como? Reindexou TODAS as bases?

Durante esse processo, tive o mesmo problema duas vezes, qdo o
indice chegou numa determinada tabela, ao invés de executar o
script em lote, fiz tabela a tabela, e passou do ponto que dava erro.

O reindex de todas as tabelas terminou, e subi o banco novamente...

Duas horas depois, a mesma coisa com o aumento do acesso:
*10.11.0.2 2013-09-26 17:10:37 BRT [11516]: [1-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*10.11.0.2 2013-09-26 17:25:10 BRT [13163]: [1-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*
*
*Inclusive essa mensagem me preocupou e não tenho idéia do que
pode ser:*
*
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [1-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937579: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [2-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937581: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [3-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937583: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [4-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937585: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [5-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937586: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [6-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937588: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26

Re: [pgbr-geral] Travamento

2013-09-03 Por tôpico Jean Pereira


Bom dia,

Somente para dar um retorno...
Não conseguimos detectar nada no hardware até agora, nem mesmo o suporte 
contratado não achou problemas.
Estou levando seriamente a hipótese que o Flavio comentou sobre os 
canais que ligam o servidor com a storage terem dado algum problema.


Mais de todo modo, até o momento não ocorreu mais problemas.

Abraço
Jean Pereira

On 08/21/2013 07:58 AM, Jean Pereira wrote:

On 08/20/2013 22:45, Aldrey Galindo wrote:

Jean,

   Estranho realmente não aparecer nada los logs, como mencionado por 
você. Eu já tive problemas com disco, mais normalmente eles apareciam 
no messages.
   O que recomendo é que caso ocorra o problema novamente, tente 
verificar na hora a estrutura dos discos (multipath -l, pvscan). 
Pois, assim pode vê se nesses momentos ele está se perdendo.
   Seria bom também ver como está a utilização dos discos com o 'sar 
-d' e a fila de processamento com o 'vmstat 2' (a cada 2 segundos). 
Se tiver com grande utilização dos discos e a fila estiver muito 
grande, aí é indicativo de que não está funcionando bem sua estrutura.



Obrigado pela dica!


Atenciosamente,
Aldrey Galindo



___
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] Travamento

2013-08-21 Por tôpico Jean Pereira


On 08/20/2013 22:45, Aldrey Galindo wrote:

Jean,

   Estranho realmente não aparecer nada los logs, como mencionado por 
você. Eu já tive problemas com disco, mais normalmente eles apareciam 
no messages.
   O que recomendo é que caso ocorra o problema novamente, tente 
verificar na hora a estrutura dos discos (multipath -l, pvscan). Pois, 
assim pode vê se nesses momentos ele está se perdendo.
   Seria bom também ver como está a utilização dos discos com o 'sar 
-d' e a fila de processamento com o 'vmstat 2' (a cada 2 segundos). Se 
tiver com grande utilização dos discos e a fila estiver muito grande, 
aí é indicativo de que não está funcionando bem sua estrutura.



Obrigado pela dica!


Atenciosamente,
Aldrey Galindo



___
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] Travamento


Bom dia.

Ontem a noite o banco travou aqui para mim, em um situação estranha.
Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS 
6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local 
2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 
x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on 
x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 
4.4.7-3), 64-bit).


Já tive um problema sério com essa maquina, que no qual existia um 
problema com o modulo de video, o que fazia todas as CPUs travarem em 
100%, e a unica solução para ela voltar a funcionar era utilizando o 
botão power.
Mas dessa vez aparentemente o servidor estava OK, e somente o postgres 
não respondia, simplismente não o conseguia nem mesmo parar ele.
Só para constar, não apareceu nada em log algum (dmesg, messages, do 
postgres, etc..), nada mesmo.
Como não tinha como matar os processos do banco foi obrigado a dar um 
reboot, que no qual também não foi bem sucedido, que no qual ficou 
travado no ponto de montagem para com a storage (o OS não conseguia 
desmontar a unidade, nem a pau). A solução foi no botão power mesmo.


Gostaria de uma opinião de vocês, já que conhecem melhor o banco.
Eu acredito que seja problema com o servidor e não com o postgres, mas 
em todos os casos não custa perguntar, talvez alguem já tenha passado 
por isso ou seja um bug e tal.


Agradeço desde já.
Jean Pereira.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Travamento


On 08/20/2013 10:26, Guimarães Faria Corcete DUTRA, Leandro wrote:

2013/8/20 Jean Pereira ad...@olostech.com:

Já tive um problema sério com essa maquina, que no qual existia um problema
com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica
solução para ela voltar a funcionar era utilizando o botão power.

Problema já resolvido?

Esse já, o suporte contratado demorou mais resolveu.




Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não
respondia, simplismente não o conseguia nem mesmo parar ele.
Só para constar, não apareceu nada em log algum (dmesg, messages, do
postgres, etc..), nada mesmo.

Isso não quer dizer muita coisa…



Como não tinha como matar os processos do banco foi obrigado a dar um
reboot, que no qual também não foi bem sucedido, que no qual ficou travado
no ponto de montagem para com a storage (o OS não conseguia desmontar a
unidade, nem a pau). A solução foi no botão power mesmo.

Problema de E/S, mas sem testes fica difícil falar qualquer coisa.  Ao
reiniciar sem diagnóstico, você perdeu a oportunidade de ver algo sem
esperar pelo próximo problema.

Eu não lembro mais do ferramental todo, mas a primeira coisa que eu
olharia, tentando prevenir algum problema futuro, seriam as
ferramentas de monitoramento Smart (das unidades de armazenamento) e
de diagnóstico do sistemas de arquivos, lembrando também de olhar se
algum dos sistemas de arquivos foi verificado e gerou algum alerta na
reinicialização.
Sim, entendo. Mais 1 minuto para mim parado é muito, sei dos problemas 
que possivelmente podem acontecer quanto a isso. Mas tenho servidor 
reserva, e devo efetuar a troca o mais rápido possível.
Quanto ao tempo de parada... o banco faz parte de um sistema de saúde, 
que no qual tem alguns PA e PS 24h.

Creio que os gurus de plantão acrescentarão detalhes mais úteis que
minhas idéias genéricas…
___
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] Travamento


On 08/20/2013 10:47, Flavio Henrique Araque Gurgel wrote:

Em 20-08-2013 10:03, Jean Pereira escreveu:

Bom dia.

Ontem a noite o banco travou aqui para mim, em um situação estranha.
Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS
6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local
2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on
x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat
4.4.7-3), 64-bit).


Gostei disso aqui. Bastante informação útil.


Já tive um problema sério com essa maquina, que no qual existia um
problema com o modulo de video, o que fazia todas as CPUs travarem em
100%, e a unica solução para ela voltar a funcionar era utilizando o
botão power.
Mas dessa vez aparentemente o servidor estava OK, e somente o postgres
não respondia, simplismente não o conseguia nem mesmo parar ele.
Só para constar, não apareceu nada em log algum (dmesg, messages, do
postgres, etc..), nada mesmo.
Como não tinha como matar os processos do banco foi obrigado a dar um
reboot, que no qual também não foi bem sucedido, que no qual ficou
travado no ponto de montagem para com a storage (o OS não conseguia
desmontar a unidade, nem a pau). A solução foi no botão power mesmo.


Duas coisas devem ter acontecido:
1) o S.O. não quis desmontar a unidade porque tinha escrita pendente e 
ele estava inacessível;
2) o PostgreSQL não pode ser parado tão facilmente quando tem conexões 
ainda e, talvez, transações em andamento.



Gostaria de uma opinião de vocês, já que conhecem melhor o banco.
Eu acredito que seja problema com o servidor e não com o postgres, mas
em todos os casos não custa perguntar, talvez alguem já tenha passado
por isso ou seja um bug e tal.


Olhe novamente no messages. Procure por indisponibilidade um (ou mais) 
canais de fibra pro Storage. Já aconteceu comigo de fibra cair e 
voltar, mesmo que rapidamente, é o suficiente pra bagunçar as coisas 
de uma forma bem bacana.


Flavio, pior que não tem nada no messages mesmo, isso que está me 
deixando com a pulga atrás da orelha.
Sobre os cabos, conferi eles no ato, mesmo assim, pela lógica, tenho 
redundancia de HBA e de Modulo controlador, na teoria 1 cabo não deveria 
dar isso, eu não tenho muita experiencia em hardware, mais acho eu que 
não deveria.
Pergunta: qual sistema de arquivos está usando, e quantos pontos de 
montagem estão disponíveis para o banco?

ext4
Segue mais informações:

   [root@olosdb01 ~]# df -h
   FilesystemSize  Used Avail Use% Mounted on
   /dev/sda1  49G  3.0G   43G   7% /
   tmpfs  32G 0   32G   0% /dev/shm
   /dev/mapper/mpathcp1  1.4T   94G  1.2T   8% /opt/md3200/pgdata
   /dev/mapper/mpathbp1  275G  1.3G  260G   1% /opt/md3200/pgxlog
   /dev/sda5 283G   37G  232G  14% /usr/local/pgsql
   /dev/sda2  97G  279M   91G   1% /var/log
   [root@olosdb01 ~]# multipath -ll
   mpathc (36d4ae52000996c41085151dbf626) dm-1 DELL,MD32xx
   size=1.4T features='3 queue_if_no_path pg_init_retries 50'
   hwhandler='1 rdac' wp=rw
   |-+- policy='round-robin 0' prio=6 status=active
   | |- 1:0:0:1 sdc 8:32  active ready running
   | `- 2:0:1:1 sdi 8:128 active ready running
   `-+- policy='round-robin 0' prio=1 status=enabled
  |- 1:0:1:1 sde 8:64  active ghost running
  `- 2:0:0:1 sdg 8:96  active ghost running
   mpathb (36d4ae5200099721d081d51dbf5b8) dm-0 DELL,MD32xx
   size=279G features='3 queue_if_no_path pg_init_retries 50'
   hwhandler='1 rdac' wp=rw
   |-+- policy='round-robin 0' prio=6 status=active
   | |- 1:0:1:0 sdd 8:48  active ready running
   | `- 2:0:0:0 sdf 8:80  active ready running
   `-+- policy='round-robin 0' prio=1 status=enabled
  |- 1:0:0:0 sdb 8:16  active ghost running
  `- 2:0:1:0 sdh 8:112 active ghost running




[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
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] Travamento


On 08/20/2013 16:24, Flavio Henrique Araque Gurgel wrote:

Em 20-08-2013 16:23, Jean Pereira escreveu:

Flavio, pior que não tem nada no messages mesmo, isso que está me
deixando com a pulga atrás da orelha.


Ora pois...
O messages (caso do CentOS) tem que ter todas as mensagens do kernel 
desde o momento do boot.


Como assim, não tem *nada*?

Bom, melhor explicar.
Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando 
coloquei novamente esta maquina em produção.


Algo parecido, acontecia com o problema que essa maquina apresentou, e 
que aparentemente foi resolvido. Nada nos logs de informação de problemas.





[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
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] Travamento


On 08/20/2013 16:37, Flavio Henrique Araque Gurgel wrote:

Em 20-08-2013 16:28, Jean Pereira escreveu:

Bom, melhor explicar.
Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando
coloquei novamente esta maquina em produção.

Algo parecido, acontecia com o problema que essa maquina apresentou, e
que aparentemente foi resolvido. Nada nos logs de informação de
problemas.


Olha amigo, então o negócio me parece hardware.
Você disse que não conseguiu matar o processo do PostgreSQL. Como 
tentou esse tiro? Você ainda tinha acesso ao console, usou ssh, usou 
pg_ctl, usou kill?
Bom, primeiro eu tentei via ssh com o '/etc/init.d/postgresql stop' (o 
arquivo do contrib/), esperei alguns minutos, alguns mesmo, depois vi 
que não tinha geito por ele, e então por via das duvidas fiz o acesso e 
a tentativa direto no terminal do servidor, ai tentei no 'pg_ctl -m 
immediate', aonde também não tive sucesso, por fim fiz um 'kill -9' do 
processo do banco, que no qual também não foi. Não consegui de maneira 
alguma matar o postgres.


Digamos que é o que nós aqui já imaginavamos, mas não custa trocar 
ideias sobre o assunto, a gente cresce com isso.


Obrigado,
Se tiver alguma dica ou sugestão, fica a vontade Flavio.



[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
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] PGBR-2013

2013-07-26 Por tôpico Jean Pereira


Bom dia.

Bom, não sei se é o caso, mas me parece que tem procura as lembranças.
Eu não sei quem sempre corre atrás disso, e também não sei a questão do 
tempo dessa pessoa.

Mas será que não seria interessante ter um estilo de venda disso?
Já que é dificil toda a comunidade ir no PGBR.
É apenas uma sugestão.

Abraço.

On 07/25/2013 19:19, Carlos Antônio Pereira (VidaUTI) wrote:

Boa noite, pessoal.
Estive olhando no site do evento PGBR2013 e não vi nada a respeito
das lembranças (camisetas, canecas, etc) e gostaria de saber se já tem 
algo disponível,

bem como coisas dos eventos anteriores.
Lembro que estive no PgConference em 2007 e tinham umas camisas legais
e muito boas (já duram 6 anos, hehehe).
Att Carlos


___
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] Restaurar base linux em windows

2013-06-27 Por tôpico Jean Domingues

Pessoal,

queria saber se é possível restaurar uma cópia da pasta de dados do linux em um 
servidor pg de mesma versão no windows (64 bits nos dois).___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Restaurar base linux em windows

2013-06-27 Por tôpico Jean Domingues

 Pessoal,
 
 queria saber se é possível restaurar uma cópia da pasta de dados do linux em
 um servidor pg de mesma versão no windows (64 bits nos dois).

 bom dia,
 negativo, somente um dump, devido o filesystem diferente.
 vc nao consegue nem se for de linux para linux, e se a instalação é 64 e o
 destino 32 bits, ou vice versa.

A questão não é o sistema de arquivos, mas o sistema operacional mesmo.
Os arquivos de dados do PostgreSQL é que ficam diferentes de um S.O. pra outro 
ou de uma arquitetura para outra.
Um PostgreSQL num Solaris com ZFS não pode ser copiado para um FreeBSD com 
ZFS, também não funcionará.



OK, pessoal. Obrigado a todos pelas respostas.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Restaurar base linux em windows

2013-06-27 Por tôpico Jean Domingues

Eu tenho o seguinte senário:


Servidor: Linux 64bits, Postgres 9.1


Maquina desenvolvimento: Windows 64bits, Postgres 9.1


Para administrar as bases utilizo PgAdmin3 no Windows, faço backup e restore 
tranquilamente entre as máquinas.


Utilizo o Codepage UTF-8 atualmente


Marcelo, você está se referindo a dump. Eu me refiro a cópia física da pasta de 
dados.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Possivel bug no pg

2013-06-10 Por tôpico Jean Domingues

Cadê um teste que comprove o possível bug?

 Uso a versão 9.1.1 64 bits no Windows 7 64.
 
Antes de dizer que é um bug teste pelo menos na *última* versão
corretiva (atualmente 9.1.9).
   Euler Taveira                   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento


Oi Euler, tentei reproduzir com uma função mais simples, mas não consegui. Se 
não se importa, estou colando a função com o erro abaixo. Vou atualizar a 
versão pra ver se resolve. De qualquer forma, só queria se saber se não sou eu 
que não estou entendo o mecanismo de error trapping. Comentei na função onde o 
erro ocorreu e o insert que deveria ter sido voltado pra trás, mas não foi. O 
erro que aconteceu naquele ponto foi tratado no único exception when other. 
Realmente não consegui reproduzir.

CREATE OR REPLACE FUNCTION public.sp_cobranca_processar_arquivo (
  psequencia integer,
  pdataprocessamento date,
  pconteudo text,
  pregistros text
)
RETURNS integer AS
$body$
DECLARE
    regCR contas_receber;
    xBoleto varchar;
    xDataCred date;
    xDesc numeric;
    xJuros numeric;
    xAcresc numeric;
    xMulta numeric;
    xAbat numeric;
    xVlrRem numeric;
    xVlrPago numeric;
    xIdArquivo integer;
    xMsg text;
    xTxt text;
    regBx record;
BEGIN
-- pregistros: 
boleto;;data_credito;;multa;;juros;;acrescimos;;desconto;;abatimento;;pago[#$]

if psequencia is null then
    return 0;
    end if;

    select nextval('seq_cobranca_arquivo')
    into xIdArquivo;

    insert into cobranca_arquivo(id,data_import_geracao,tipo_arquivo,           
                                   -  insert que 
deveria ter tipo rollback
    sequencial,data_processamento,conteudo)
    values(xIdArquivo,CURRENT_TIMESTAMP,'2',psequencia,pdataprocessamento,
    pconteudo);

    xMsg = '';

-- pregistros: 
boleto;;data_credito;;multa;;juros;;acrescimos;;desconto;;abatimento;;pago[#$]
    for xBoleto,xDataCred,xMulta,xJuros,xAcresc,xDesc,xAbat,xVlrPago 
    in select c1::varchar,c2::date,c3::numeric,c4::numeric,c5::numeric,
    c6::numeric,c7::numeric,c8::numeric
    from sp_texto_to_record(pregistros)
    loop
        if xMsg  '' then
        xMsg = trim(xMsg) || E'\r\n';
        end if;

    select * from contas_receber x
        where x.boleto = xBoleto::integer
        order by id desc limit 1 -- apenas o ultimo
        into regCR;                                                    
-
  o erro aconteceu bem aqui

        if not found then
        xMsg = xMsg || '- (Erro) Boleto ' || xBoleto || ' não localizado';
            continue;
        elseif regCR.data_pagto is not null then
        xMsg = xMsg || '- (Aviso) Boleto ' || xBoleto || ' já está baixado';
            continue;
        end if;

        begin 
            -- consolidar todas as remanescentes na c.r. a baixar
            select array_to_string(array(select ret_id from 
            sp_qry_contas_receber_remanesc(regCR.id)),'#$')
            into xTxt;

            if coalesce(xTxt,'')  '' then
                perform sp_gravar_contas_remanescentes(regCR.id, xTxt);
            end if;

            select * from sp_qry_contas_receber(null,null,null,null,null,null,
            null,regCR.id,xDataCred,null) into regBx; -- atualizado

            -- baixar
            xJuros = xJuros + xMulta + xAcresc;

            if xJuros  regBx.ret_juros_devidos then
                xJuros = regBx.ret_juros_devidos;
            end if;

            xDesc = xDesc + xAbat;

            xVlrRem = regBx.ret_valor + regBx.ret_valor_residual 
            + xJuros - xDesc - xVlrPago;

            if xVlrRem  0 then
            xVlrRem = 0;
            end if;

            update contas_receber set 
            desconto = xDesc, 
            juros = xJuros, 
            valor_remanesc = xVlrRem, 
            data_pagto = xDataCred, 
            id_arquivo_retorno = xIdArquivo
            where id = regCR.id;

            xMsg = xMsg || '- Boleto ' || xBoleto || ' baixado com sucesso';    
    
        exception when others then
            xMsg = xMsg || '- (Erro) Boleto ' || xBoleto || ' - ' || sqlerrm;
        end;
    end loop; 

    update cobranca_arquivo set
    historico = trim(xMsg)
    where id = xIdArquivo;

    return xIdArquivo;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;                                                                       
                                                                 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Possivel bug no pg

2013-06-07 Por tôpico Jean Domingues

Pessoal, acho que encontrei um bug no pg. Não sei se é aqui que eu deveria 
postar, mas talvez eu esteja enganado também. Tenho uma função como abaixo:


begin
  a) 
     
     
   for reg in select .
   loop
      
      
      begin
          b) 
             
      exception when others then
          c) .
      end;
   end loop;
   

   
end;

Percebi que, um erro em a, que deveria ter sido propagado para o chamador, 
foi capturado em c. Creio que seja por conta do bloco estar dentro de um 
loop, e algum ponteiro ter ficado preso neste exception trapping.

Uso a versão 9.1.1 64 bits no Windows 7 64.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Biometria.

2013-05-15 Por tôpico Jean Domingues

  E desconsiderando a biometria, também irei trabalhar com digitalização

  de imagens.
  A performance cai bastante se guardado na base de dados? 
  Já pensei na possibilidade de guardar arquivos na base de dados, mas
  somente pelas 
  questões mencionadas abaixo, pois ao meu ver, o gerenciamento de arquivo
  pelo 
  sistema operacional é melhor. Além das vantagens abaixo, há alguma a
  mais a ser
  considerada?


Eu acredito que as vantagens de armazenar as imagens no banco de dados são 
grandes. E recomendo fazer assim: ter uma tabela só as as imagens e uma chave 
primária (um serial por exemplo). Daí, referencia essa tabela nas outras. Mas é 
apenas uma ideia de implementação.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mudar Charset num Select ?

2013-05-10 Por tôpico Jean Domingues

Pessoal, estou tendo problemas de novo com caracteres
Tenho um formulario num site que o usuário pode colar um texto do maldito word 
que enche o arquivo de lixo.
Acontece que quando tento abrir esse texto no Delphi, mais precisamente num 
componente ZQuery (suite Zeos) ele grita por causa do tipo de caractere usado.
Bem no site eu uso UTF-8, mas na aplicação tenho que usar LATIN1, porque foi 
começado assim e não tem como mudar.


Bem, mais uma solução paliativa:


Tem como mudar o CodePage somente em um select pra ele entender que é UTF-8 ?
Para não ter que mudar no resto da aplicação.




Mais uma vez conto com a ajuda dos colegas


Se voce estiver armazenando o rtf inteiro, use bytea. É uma saída.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Select with lock.

2013-05-08 Por tôpico Jean Domingues

Mas infelizmente não dá pra usar a sequense, seria algo como isso, mas não é 
um incremento, o nº de selo se repete todas as
vezes que adquiro uma nova remessa de uma determinada categoria, a cada 
remessa inicia de zero. Não é algo como eu gere o próximo número, mas sim eu 
cadastro esta numeração na base de dados.


Não daria pra usar sequences pra cada remessa. Por exemplo, aqui na empresa, eu 
controlo a numeração de boletos para cada conta corrente. Então eu crio as 
sequences (sob demanda, via codigo), dessa forma:
seq_boleto_cc_1
seq_boleto_cc_2
seq_boleto_cc_n
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Stored Procedure.

2013-04-26 Por tôpico Jean Domingues


Tudo bem pessoal, como disse anteriormente, é minha primeira stored procedure 
no postgresql e é uma conversão do firebird para postgresql, do jeito que está 
lá estava convertendo. Se tiverem e poderem, por favor, me passem uma stored 
procedure que retorna registros. Obrigado!


Izaque, funciona assim:

se quiser retornar varios registros, set of tipo, e  retorno tem que ser com 
return next. Se o tipo for um tipo simples, como integer, use return next 
valor. Se tipo for record, entao os campos retornados serão os parametros do 
tipo out ou in/out. Neste caso, use apenas return next, sem parametro nenhum. 
Cada return next retorna um registro (pode ser num loop, por exemplo). Se o 
tipo do retorno nao for Set Of, entao use apenas return valor, com o valor do 
tipo da funcao.

Use o SqlManager ou PgManager da EMS pra te facilitar o servico.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Stored Procedure.

2013-04-25 Por tôpico Jean Domingues

Mas vc esta retornando um record onde deveria retornar numeric. E, se for set 
of, retorne com return next (varios registros), senao, nao use setof, use 
apenas numeric no tipo do retorno.




 De: izaque Maciel izaquemac...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br 
Enviadas: Quinta-feira, 25 de Abril de 2013 8:11
Assunto: [pgbr-geral] Stored Procedure.
 


Bom dia pessoal, não consegui concluir esta procedure pela questão do retorno, 
que tem que me retornar todos os campos do último select abaixo, e com o 
retorno deste último select, criarei outra stored procedure para pegar o 
retorno dessa e trabalharei alguns cálculos. Peço a ajuda de vocês, obrigado.




CREATE OR REPLACE FUNCTION public.retorna_valores_go (
  id_emolumento numeric(12,2),
  dt_calculo_emol date,
  valor_documento numeric(12,2)
)
RETURNS SETOF numeric AS
$body$
DECLARE


  vidEmolumento numeric(12,2);
  vidVigencia numeric(12,2);
  vidEmolItens numeric(12,2);
  regEmolItens record;
BEGIN


  -- Verifica se existe o emolumento
  select e.id into vidEmolumento
  from emolumentos e
  where e.id = id_emolumento;


  -- Se encontrado, localiza a vigência
  if (videmolumento is not null) then
  begin
  select v.id into vidvigencia
    from vigencia v
    where dt_calculo_emol between v.dt_inicial and v.dt_final;


    -- Se econtrada a vigência, localiza o emolumento pelo valor
    if (vidvigencia is not null) then
      select e.id into videmolitens
      from emolumentos_itens e
      where valor_documento between e.fx_valor_final and e.fx_valor_final;
    end if;


    -- Se foi localizado o emolumento
    if (videmolitens is not null) then
      select e.id into videmolitens
      from emolumentos_itens e
      where e.id_emolumentos  = videmolumento and
            e.id_vigencia = vidvigencia and
            e.fx_valor_inicial = 0 and
            e.fx_valor_final   = 0;
    end if;


    if (videmolitens is not null) then
    begin
      select e.id,
             e.id_emolumentos,
             e.fx_valor_inicial,
             e.fx_valor_final,
             e.valor_emolumento,
             e.tx_jud,
             e.fundesp,
             e.valor2,
             e.valor3,
             e.valor4,
             e.valor5,
             e.outras_despesas,
             e.pag_extra_inicio,
             e.valor_pag_extra,
             e.fundo_pag_extra,
             e.tx_jud_pag_extra,
             e.cod_tab_correg,
             e.cod_interno,
             e.calc_txjud,
             e.calc_fundesp,
             e.calc_valor2,
             e.calc_valor3,
             e.calc_valor4,
             e.calc_valor5,
             e.calc_pagina_extra into regEmolItens
  from emolumentos_itens e
      where valor_documento between e.fx_valor_final and e.fx_valor_final;


      return regEmolItens;
    end;
    end if;
  end;
  end if;




END
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;
___
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] WORD 2013

2013-04-23 Por tôpico Jean Domingues

Oi Pessoal!!!

Alguem já teve que conectar uma base do pg no word 2013?
Preciso fazer etiquetas! E não estou conseguindo!!!
No libreoffice faço com uma mão nas costas, agora, no word

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

Re: [pgbr-geral] Registro tava e pronto

2013-04-12 Por tôpico Jean Pereira



On 04/12/2013 15:25, Marcelo da Silva wrote:
Pessoal, tem hora que um registro trava e quem diz que consigo fazer 
algo nele

Eu não uso Lock em nada


Bom, tens como detalhar um pouco melhor, fica mais fácil para te ajudar.


As vezes por uma queda de rede, sei lá
Só sei que um tal registro tarava e não consigo deletar, update, só select

COmo destravar nessa situação ?

Eu estou tendo que reiniciar o postgres pra conseguir dar um update no 
registro



Marcelo Silva
---


___
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] Iniciante

2013-04-11 Por tôpico Jean Domingues


Por causa do tunelamento que o firebird exige, como a aplicação dependera de 
uma rede externa o firebird me dará dor de cabeça, sei que ele e um otimo DGDB 
porem creio que para esta aplicação terei que migrar

Veja bem: a questão de tunelamento, na verdade é pra compactação de pacotes. 
Neste caso, nem mesmo o PG foi feito para ser acessado em rede de baixa 
performance diretamente, apesar de a resposta ser muitas vezes mais rápida (já 
testei). Eu usava o FB também e só mudei por conta dos recursos do PG pra 
grandes sistemas, como replicação nativa, hot-standby, entre outros. Se você 
escreve muitas procedures e triggers (que é o meu caso), sentirá alguma 
dificuldade, pois ele é late-binding pra validar ao compilar (o FB é mais 
restritivo neste sentido, e evita erros de programação).___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Parametros para uma PL

2013-04-10 Por tôpico Jean Domingues

Bom minha duvida, tenho uma necessidade de passar 15 parametros para uma PL, 
existe alguma recomendação, ou sugestão para o caso.


Terei casos usando versão 9.2 e 8.2 (sendo atualizados gradualmente)


Obrigado a todos








Mas... qual a dificuldade de usar os 15 parametros?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Instalar Plugin de Debugger no Linux

2013-04-04 Por tôpico Jean Domingues



Pessoal, eu fiz a instalação do postgresql 9.2 na unha. Agora, preciso da 
biblioteca plugin_debugger.so no linux e não sei como conseguir ou compilar. 
Se alguém souber e puder me ajudar, agradeço.


Olá Jean,

Apesar do post [1] ter sido feito usando o PG 9.1 creio que não terás problema 
em adaptar para o PG 9.2.


Att,


[1] 
http://fabriziomello.blogspot.com.br/2012/05/instalarconfigurar-debugador-de-plpgsql.html


Fabricio... valeu... era isso mesmo.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Voltando ao assunto, mas com outra visão (CHAR ou VARCHAR) ?

2013-04-02 Por tôpico Jean Domingues

A final, deve-se ou não usar o CHAR sendo que existe o VARCHAR ?
Pra mim o CHAR seria mais rápido por ter um tamanho fixo, mas pela matéria 
mostra-se o inverso!!!
Sei que a matéria fala sobre o Oracle, mas como o Postgres no meu ver tem 
muito a ver com ele, como se comportar no caso do CHAR e VARCHAR do postgres ?
* Sei que existem muitas matérias na web sobre o postgres, mas gostaria de 
saber a opinião do especialistas aqui da lista :) (acho mais confiável, rsrsr)



Tip: There are no performance differences between these three types, apart from 
increased storage size when using the blank-padded type, and a few extra cycles 
to check the length when storing into a length-constrained column. While 
character(n) has performance advantages in some other database systems, it has 
no such advantages inPostgreSQL. In most situations text or character varying 
should be used instead.


http://www.postgresql.org/docs/9.2/static/datatype-character.html


Entendo que a diferença seria apenas de espaço em disco mesmo. Use varchar e 
boa.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Saber quem esta usando uma tabela

2013-04-01 Por tôpico Jean Domingues

Em 1 de abril de 2013 11:19, Marcelo da Silva marc...@ig.com.br escreveu:
 Pessoal, as vezes preciso executar alterações numa tabela, e se ele estiver
 sendo usada não consigo.

 Tem como saber se aquela tabela está sendo usada e por quem (IP por exemplo)
 antes de executar a tal alteração ?

Sim.

Por que se dar ao trabalho de dar uma resposta inútil como esta? Espero que 
seja brincadeira.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] descobrir nas System Tables quais tabelas de um schema, utilizam uma certa coluna como FK

2013-03-28 Por tôpico Jean Pereira


On 03/27/2013 23:44, Marcos Aurelio Nobre wrote:

sALLdações .

Boa noite. Estou precisando de uma ajuda.

Em um servidor 9.1 tenho três schemas A, B e C

Em A há uma tabela X que tem a coluna C como sua PK

Em B há 30 tabelas que tem C como FK com a DRI : ON UPDATE CASCADE ON 
DELETE NO ACTION.


Em C há 400 tabelas e 80% delas tem C como FK, porém sem DRI 
implementado nas contraints.


Então eu não gostaria de entrar em cerca de 200 ~ 300 tabelas , 
excluir as FK-Constraints que referem-se / mencionam C e recriá-las 
com a DRI de update-cascade.


Assim eu vos pergunto:

1) Existe algum commando de DDL tipo ALTER CONSTRAINT . que 
pudesse ser aplicado a estas tabela, modificando-lhes ou 
incorporando-lhes um UPDATE CASCADE ?
Bom... acho eu que não... mais tem outras pessoas que podem te ajudar 
nisso...


2) Existe algum SELECT que possa ser aplicado às SYSTEM TABLES de modo 
que eu descubra quais tabelas utilizam a coluna C como foreign key ?


Talvez ajude você..

   SELECT distinct tc.constraint_name,
tc.constraint_type,
tc.table_schema,
tc.table_name,
kcu.column_name,
tc.is_deferrable,
tc.initially_deferred,
rc.match_option AS match_type,
rc.update_rule AS on_update,
rc.delete_rule AS on_delete,
ccu.table_schema,
ccu.table_name AS references_table,
ccu.column_name AS references_field
   FROM information_schema.table_constraints tc
LEFT JOIN information_schema.key_column_usage kcu
ON tc.constraint_catalog = kcu.constraint_catalog
AND tc.constraint_schema = kcu.constraint_schema
AND tc.constraint_name = kcu.constraint_name
LEFT JOIN information_schema.referential_constraints rc
ON tc.constraint_catalog = rc.constraint_catalog
AND tc.constraint_schema = rc.constraint_schema
AND tc.constraint_name = rc.constraint_name
LEFT JOIN information_schema.constraint_column_usage ccu
ON rc.unique_constraint_catalog = ccu.constraint_catalog
AND rc.unique_constraint_schema = ccu.constraint_schema
AND rc.unique_constraint_name = ccu.constraint_name
   WHERE lower(tc.constraint_type) in ('foreign key')
AND ccu.table_name = 'nome da tablea que tens a PK'
--AND ccu.column_name = 'campo PK'
--AND kcu.column_name = 'nome do campo nas FK'
   order by tc.constraint_name




3) Outra variante de consulta e descobrir qual constraint utiliza

Gratos:

MN


___
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] Melhor forma de fazer esta query

2013-03-26 Por tôpico Jean Pereira


On 03/26/2013 12:24, Marco Aurélio V. da Silva wrote:

Caros tenho uma tabela com a seguinte estrutura:
ip  varchar(20)
download  numeric(18,0)
upd_timestamp  timestamp
com os seguintes dados
ip   download   upd_timestamp
192.168.0.1   150 2013-03-25 20:00
192.168.0.1   300 2013-03-25-21:00
192.168.0.1   450 2013-03-25-22:00
192.168.0.2   150 2013-03-25 20:00
192.168.0.2   430 2013-03-25 21:00
Gostaria de pegar apenas a ultima ocorrencia de cada ip por dia, 
preciso pegar os seguintes dados

192.168.0.1450 2013-03-25  22:00
192.168.0.2   430  2013-03-25 21:00
Sugestões  ?

Bom... não sei se é a melhor forma, ou a mais adequada, mas creio que ajude

select distinct ip,
first_value(upd_timestamp) OVER (PARTITION BY ip, 
data_hora_registro::date ORDER BY data_hora_registro desc) as upd ,
first_value(download) OVER (PARTITION BY ip, upd_timestamp::date ORDER 
BY upd_timestamp desc) as ultimo

from tabela


talvez isso?


Desde já agradeço a atenção recebida.
Marco Aurélio V. da Silva
marcoprod...@gmail.com
Prodata Informática e Cad. Ltda
(33) 3322-


___
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] Multi Thread

2013-03-20 Por tôpico Jean Domingues

O que eu acho estranho é um sistema de grande porte [ ERP ] trabalhar assim, 
imagina gerar um balancete de um ano e o sistema usar um só núcleo pra fazer 
tudo isso, sendo que tem disponível outros 7 núcleos. 


Agora fiquei curioso. Se eu faço uma consulta que me retornará os dados para o 
balancete, como a aplicação cliente dividiria essa consulta para executar em 
vários cores?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problema na lista

2013-03-07 Por tôpico Jean Pereira


On 03/06/2013 01:24, Antonio Cesar wrote:
Pessoal estou sem receber mensagem a 5 dias, a lista esta com algum 
problema?


Bom, é possivel que seja uma instabilidade (como já dito pelo Fábio 
Telles aqui na lista), ou também, pode ser que ninguem movimentou a lista.


Mas, quem pode confirmar isso é o Telles.

Abraço



___
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] ÍNDICES EM TABELAS QUE RECEBEM MUITOS INSERTS, UPDATES

2013-02-08 Por tôpico Jean Pereira


Bom dia.

Bom, tenho uma situação muito parecida por aqui.
Temos um banco de dados que nasceu no access a muitos e muitos anos 
atrás, foi para sqlserver e a muitos anos está no postgresql.


Trabalhamos com sistema de saúde publica, e nossas tabelas de produção 
(digo os dados de procedimentos executados e tal), são uma porcaria, e 
para alterar essas tabelas é o bixo.


Minha solução foi adotar esses índices pelo qual você referiu, mas eu 
não sei essa informação também.
Mas, pelo que constatamos por aqui, a melhora foi muito significativa, e 
até agora não detectamos problemas perante aos índices.


Abraço.

On 02/08/2013 09:47, Wellington Openheimer wrote:

Olá pessoal,

Temos uma tabela que em um determinado tempo ela é muito consultada e 
ao mesmo tempo sofre muitos inserts e updates.


Acontece que a consulta é bem complexa e está ficando cada vez mais 
lenta com o aumento do número de dados.


Decidimos então testar a criação de uns índices com os principais 
campos nas cláusulas WHERE das consultas mais lentas.


A consulta ficou bem mais rápida, mas estamos receosos se estes 
índices irão deixar mais lenta a inserção e update de dados

pois esses comandos teriam então que inserir no índice também.


Obs.:

Criamos 2 índices compostos btree.
 (campo1, campo2, campo3)
 (campo4, campo2, campo3)

campo2 e campo3 fazem parte da chave da tabela que possui 5 campos chave.

Detalhe: temos 2 consultas muito pesadas que usam no where campo1, 
campo2 e campo3 e campo4, campo2 e campo3 respectivamente.



Seremos muito grato se puderem nos ajudar.


att,

Wellington



___
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] Trigger de alterações

2013-01-14 Por tôpico Jean Domingues

Senhores desculpe abusar da bondade de vocês, mas ainda manjo pouco de 
triggers no Postgres.
 
Tenho a seguinte necessidade:
 
TabelaA, quando alterada grava as diferenças na TabelaB
 
Por exemplo a grosso modo no delphi eu faço
 
for i=0 to FieldsCount-1 do 
begin
  if (Campo[i].NewValue  Campo[i].OldValue) then
  begin
    Insert na TabelaB
  end
end;
 
Então a dúvida:
 
Como contar os campos de uma tabela verificando o Old e New Values (de cada 
campo) pra dar um insert em outra tabela ?
 
Seria como gravar um log de eventos.
 
 
Mais uma vez muito obrigado pela atenção
 


Marcelo, tenho usado a seguinte trigger function para fazer log. Talvez ela te 
sirva ou ajude. Ela tem que ser chamada numa trigger after insert/delete/update.

CREATE OR REPLACE FUNCTION public.log_to_audit_table (
)
RETURNS trigger AS
$body$
DECLARE
    fieldName varchar;
    idValue TEXT;
    oldValue TEXT;
    newValue TEXT;
BEGIN
    IF (TG_OP = 'INSERT') OR (TG_OP = 'UPDATE') THEN
    -- NEW value
        EXECUTE 'SELECT coalesce(($1).id::text,)' INTO idValue USING NEW;

        FOR fieldName IN
            SELECT column_name
            FROM information_schema.columns
            WHERE table_schema = quote_ident(TG_TABLE_SCHEMA)
            AND table_name = quote_ident(TG_TABLE_NAME)
            and column_name  'id'
            ORDER BY ordinal_position
        LOOP
            -- NEW value
            EXECUTE 'SELECT coalesce(($1).' || fieldName || '::text,)' INTO 
newValue USING NEW;
            
            -- OLD value
            IF (TG_OP = 'INSERT') THEN
                oldValue := ''::varchar;
            ELSE   -- Else operation is an UPDATE, so capture the OLD value.
                EXECUTE 'SELECT coalesce(($1).' || fieldName || '::text,)' 
INTO oldValue USING OLD;
            END IF;

            IF oldValue  newValue THEN
                insert into audit_table values(CURRENT_TIMESTAMP, 
substring(CURRENT_USER, 1, 10), 
                substring(TG_TABLE_NAME, 1, 40), substring(fieldName, 1, 40), 
'id', 
                    idValue, substring(tg_op, 1, 1), oldValue, newValue); 
            END IF;
        END LOOP;
   
        RETURN NEW;
    ELSEIF (TG_OP = 'DELETE') THEN
    -- OLD value
        EXECUTE 'SELECT coalesce(($1).id::text,)' INTO idValue USING OLD;
        
        FOR fieldName IN
            SELECT column_name
            FROM information_schema.columns
            WHERE
                table_schema = quote_ident(TG_TABLE_SCHEMA)
            AND table_name = quote_ident(TG_TABLE_NAME)
            and column_name  'id'
            ORDER BY ordinal_position
        LOOP
            -- OLD value
            EXECUTE 'SELECT coalesce(($1).' || fieldName || '::text,)' INTO 
oldValue USING OLD;

            insert into audit_table values(CURRENT_TIMESTAMP, 
substring(CURRENT_USER, 1, 10), 
                substring(TG_TABLE_NAME, 1, 40), substring(fieldName, 1, 40), 
'id', 
                idValue, substring(tg_op, 1, 1), oldValue, ''); 
        END LOOP;

        RETURN OLD;
    END IF;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;


Tabela de log:

CREATE TABLE public.audit_table (
  ts TIMESTAMP WITH TIME ZONE, 
  usr VARCHAR(10), 
  tbl VARCHAR(40), 
  fld VARCHAR(40), 
  pk_name VARCHAR(30), 
  pk_value VARCHAR(20), 
  mod_type CHAR(1), 
  old_val TEXT, 
  new_val TEXT
) 
WITH (oids = false);

CREATE INDEX audit_table_idx1 ON public.audit_table
  USING btree (ts);

CREATE INDEX audit_table_idx2 ON public.audit_table
  USING btree (tbl COLLATE pg_catalog.default, pk_value COLLATE 
pg_catalog.default);

CREATE INDEX audit_table_idx3 ON public.audit_table
  USING btree (tbl COLLATE pg_catalog.default, fld COLLATE 
pg_catalog.default);

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

Re: [pgbr-geral] Demora absurda processamento comando UPDATE

2012-11-13 Por tôpico Jean Domingues

RETURNS TRIGGER
LANGUAGE plpgsql
  AS
   'BEGIN
     UPDATE public.areas SET area_shp = (SELECT ST_Area(geom)/1 FROM 
public.propriedades
     WHERE public.areas.num_prop = public.propriedades.num_prop AND 
public.areas.mun_geocodigo = public.propriedades.mun_geocodigo);
     RETURN OLD;
   END;' ; 


aqui, acho que tem que ser return old para delete, e new para insert e update;


 CREATE TRIGGER calcula_area_ha
  AFTER INSERT OR UPDATE OR DELETE
  ON public.propriedades
  FOR EACH ROW
  EXECUTE PROCEDURE calcula_area_ha();
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida - Segurança

2012-10-23 Por tôpico Jean Domingues

Creio que possa ser uma boa alternativa, se a maquina for robusta, você criar 
uma VM (Virtualbox da Oracle, por exemplo), e instalar um linux com o servidor 
postgresql. A meu ver, ficaria bem seguro.

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

[pgbr-geral] pg_basebackup

2012-10-08 Por tôpico Jean Domingues

Pessoal,

estou com duvida sobre o que informar no parametro -X de pg_basebackup. Qual o 
valor correto para que, ao final do backup, eu tenha o log gerado durante o 
backup, e nao corra o risco de ter erro ao restaurar?

Jean Domingues.___
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_basebackup

2012-10-08 Por tôpico Jean Domingues

Valeu Euler.


 estou com duvida sobre o que informar no parametro -X de pg_basebackup. Qual 
 o
 valor correto para que, ao final do backup, eu tenha o log gerado durante o
 backup, e nao corra o risco de ter erro ao restaurar?
 
Você não informou a versão mas o parâmetro -X só está disponível na 9.2
então... Com a opção -X você tem duas escolhas:

(i) fazer a cópia ao final da cópia de segurança física (-X f): para isso é
necessário ter wal_keep_segments com um valor alto o suficiente para o
postgres não reciclar os arquivos do WAL até o fim da cópia física;
(ii) fazer o envio em paralelo com a cópia de segurança física (-X s): ele
estabelece uma segunda conexão (além da que já faz a cópia física) para
transferir os arquivos do WAL ao mesmo tempo que a outra conexão transmite a
cópia física.

Eu prefiro a segunda opção já que ela não precisa que eu adivinhe um valor
para wal_keep_segments. No entanto, ela utiliza uma conexão a mais (lembrar de
adicionar 1 a max_wal_senders no servidor primário -- alteração deste
parâmetro precisa de reinício do serviço) e você utilizará mais banda durante
a execução do pg_basebackup mas, em compensação, você agilizará a cópia e
*não* corre o risco de perder arquivos do WAL durante a cópia.

Na versão 9.1, a opção (i) é a única possível.


-- 
   Euler Taveira de Oliveira - 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] Problemas com vacuumdb

2012-09-25 Por tôpico Jean Domingues

Pessoal, deixei agendado o seguinte comando para a madrugada, e para o meio do 
dia também (horários de menor intensidade de uso do servidor):

/usr/local/pgsql/bin/vacuumdb -z -v -d ideskmaestro 2 /pg/data/vacuum.log


Mas ja é a terceira vez que chego pela manha e o sistema está amarrado. Ao 
verificar os processos no servidor, o processo de vacuumdb está rodando várias 
vezes (uns 40 processos), e a solução é dar um restart no pg.

Alguém poderia me dar uma ajuda, ou um esclarecimento quanto a rotina de 
vacuum? Ps.: eu desliguei o autovacumm.

Jean Domingues
iDesk Informática.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problemas com vacuumdb

2012-09-25 Por tôpico Jean Domingues

- Mensagem original -

 De: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
 Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL 
 Brasileira pgbr-geral@listas.postgresql.org.br
 Cc: 
 Enviadas: Terça-feira, 25 de Setembro de 2012 10:33
 Assunto: Re: [pgbr-geral] Problemas com vacuumdb
 
 2012/9/25 Jean Domingues ejdom...@yahoo.com.br:
  eu desliguei o autovacumm.
 
 Por quê?  Religa, remove o teu do crontab, e relaxa… ou houve alguma
 razão específica?  Qual?
 

Houve, mas não quer dizer que eu tenha razão. Tenho uma tabela que mantém o 
histórico do estoque de cada produto no tempo. Consigo ver a posição do estoque 
em qualquer tempo passado. Porém, eu preciso fazer uma alteração muito antigo, 
a atualização em cascata do estoque gerava vários processos de vacuum. Também 
uma tabela de log de alterações disparava várias vezes o processo, derrubando a 
performance. Achei melhor controlar o processo, tipo a cada 2 horas. Errei 
feio??? 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problemas com vacuumdb

2012-09-25 Por tôpico Jean Domingues

  Houve, mas não quer dizer que eu tenha razão. Tenho uma tabela que mantém o 

 histórico do estoque de cada produto no tempo. Consigo ver a posição do 
 estoque 
 em qualquer tempo passado. Porém, eu preciso fazer uma alteração muito 
 antigo, a 
 atualização em cascata do estoque gerava vários processos de vacuum. Também 
 uma 
 tabela de log de alterações disparava várias vezes o processo, derrubando a 
 performance. Achei melhor controlar o processo, tipo a cada 2 horas. Errei 
 feio??? 
 
 Por que não desativar o autovacuum somente nessa tabelas? Ou melhor, fazer um
 tuning específico no autovacuum para essas tabelas?
 
Falta de conhecimento. Vou estudar os parametros de autovacuum da tabela.

Obrigado a todos.

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

Re: [pgbr-geral] spclocation

Pois é, macaco velho fica confiante demais no galho... hehehe. Mas o ambiente é 
controlado, dá pra arriscar. Os benefícios da nova versão me chamaram a 
atenção. A rotina em questão é de comparer, vou ter dar outro jeito (como diff 
do metadado, por exemplo).



- Mensagem original -
 De: Euler Taveira eu...@timbira.com
 Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
 Cc: 
 Enviadas: Quarta-feira, 19 de Setembro de 2012 21:25
 Assunto: Re: [pgbr-geral] spclocation
 
 On 19-09-2012 18:24, Jean Domingues wrote:
  Eu fiz uma nova instalação do servidor, compilei, configurei backup (por 
 log). Pra reverter agora vai dar trabalho.
 
 Faltou fazer o principal: homologação. Como você coloca algo em produção sem
 saber se ao menos todas as suas rotinas (processos) antigas funcionam?
 
 
 -- 
    Euler Taveira de Oliveira - 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 mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] spclocation


A EMS disse que só vai liberar atualização para 9.2 em outubro. Que coisa, não? 
O pgdiff atende o 9.2? Você usa?




 De: Vinicius Santos vinicius.santos.li...@gmail.com
Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL Brasileira 
pgbr-geral@listas.postgresql.org.br 
Enviadas: Quinta-feira, 20 de Setembro de 2012 8:31
Assunto: Re: [pgbr-geral] spclocation
 

Pois é, macaco velho fica confiante demais no galho... hehehe. Mas o ambiente 
é controlado, dá pra arriscar. Os benefícios da nova versão me chamaram a 
atenção. A rotina em questão é de comparer, vou ter dar outro jeito (como diff 
do metadado, por exemplo).


Como já disseram existe o pgdiff[1], concordo que a ferramenta da EMS é bem 
mais completa, mas o pgdiff pode atender bem a maioria dos casos. Uma pena 
estar descontinuado.

[1] = http://pgdiff.sourceforge.net/



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

Re: [pgbr-geral] spclocation

Não, mas já estou testando. Valeu.


- Mensagem original -
 De: Bruno Silva bemanuel...@gmail.com
 Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
 Cc: 
 Enviadas: Quinta-feira, 20 de Setembro de 2012 9:17
 Assunto: Re: [pgbr-geral] spclocation
 
 Eu uso muito o apgdiff e me atende bem. Você já o usou?
 
 Bruno E. A. Silva.
 Analista de Sistemas.
 
 2012/9/20 Matheus de Oliveira matioli.math...@gmail.com:
 
  2012/9/20 Vinicius Santos vinicius.santos.li...@gmail.com
 
 
  A EMS disse que só vai liberar atualização para 9.2 em outubro. Que
  coisa, não? O pgdiff atende o 9.2? Você usa?
 
 
  O pgdiff trabalha de maneira diferente da ferramenta da EMS, é como o 
 diff
  do GIT ou SVN ,da uma olhada na documentação para mais detalhes, é 
 realmente
  muito simples.
 
  Eu uso sim, e pra mim funciona bem.
 
 
  Tem também o apgdiff [1] que está não está descontinuado...
 
  [1] http://apgdiff.startnet.biz/
 
 
 
  Atenciosamente,
  --
  Matheus de Oliveira
  Analista de Banco de Dados PostgreSQL
  Dextra Sistemas - MPS.Br nível F!
  www.dextra.com.br
 
  ___
  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] spclocation

Bruno, tentei, mas ta dando o seguinte erro:

C:\Temp\SQLComparer\Program Files (x86)\Java\jre6\bin\java.exe -jar apgdiff-2
.3.jar source.sql target.sql  sync.sql


Exception in thread main java.lang.StringIndexOutOfBoundsException: String ind
ex out of range: 91
        at java.lang.String.substring(Unknown Source)
        at cz.startnet.utils.pgdiff.parsers.Parser.parseString(Parser.java:267)
        at cz.startnet.utils.pgdiff.parsers.CommentParser.getComment(CommentPars
er.java:356)
        at cz.startnet.utils.pgdiff.parsers.CommentParser.parseColumn(CommentPar
ser.java:272)
        at cz.startnet.utils.pgdiff.parsers.CommentParser.parse(CommentParser.ja
va:46)
        at cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum
pLoader.java:202)
        at cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum
pLoader.java:239)
        at cz.startnet.utils.pgdiff.PgDiff.createDiff(PgDiff.java:36)
        at cz.startnet.utils.pgdiff.Main.main(Main.java:45)


 
 Não, mas já estou testando. Valeu.
 
 
  Eu uso muito o apgdiff e me atende bem. Você já o usou?
 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] spclocation

Já achei a resposta.

https://github.com/fordfrog/apgdiff/issues/69 



- Mensagem original -
 De: Jean Domingues ejdom...@yahoo.com.br
 Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
 Cc: 
 Enviadas: Quinta-feira, 20 de Setembro de 2012 11:13
 Assunto: Re: [pgbr-geral] spclocation
 
 Bruno, tentei, mas ta dando o seguinte erro:
 
 C:\Temp\SQLComparer\Program Files 
 (x86)\Java\jre6\bin\java.exe -jar apgdiff-2
 .3.jar source.sql target.sql  sync.sql
 
 
 Exception in thread main java.lang.StringIndexOutOfBoundsException: 
 String ind
 ex out of range: 91
         at java.lang.String.substring(Unknown Source)
         at 
 cz.startnet.utils.pgdiff.parsers.Parser.parseString(Parser.java:267)
         at 
 cz.startnet.utils.pgdiff.parsers.CommentParser.getComment(CommentPars
 er.java:356)
         at 
 cz.startnet.utils.pgdiff.parsers.CommentParser.parseColumn(CommentPar
 ser.java:272)
         at 
 cz.startnet.utils.pgdiff.parsers.CommentParser.parse(CommentParser.ja
 va:46)
         at 
 cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum
 pLoader.java:202)
         at 
 cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum
 pLoader.java:239)
         at cz.startnet.utils.pgdiff.PgDiff.createDiff(PgDiff.java:36)
         at cz.startnet.utils.pgdiff.Main.main(Main.java:45)
 
 
 
  Não, mas já estou testando. Valeu.
 
 
   Eu uso muito o apgdiff e me atende bem. Você já o usou?
 
 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] spclocation

2012-09-19 Por tôpico Jean Domingues

Pessoal, 

não existe uma forma de eu contornar essa alteração que foi feita no catálogo 
do sistema? Algo como criar um campo no catálogo (se tiver falando besteira, me 
corrijam), em branco mesmo? Seria uma solução provisória, até que os 
desenvolvedores de ferramentas (EMS pra ser específico) atualizem os 
executáveis. Na verdade, estou refém do EMS Database Comparer para PostgreSQL.

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

Re: [pgbr-geral] spclocation

2012-09-19 Por tôpico Jean Domingues

Sim.


 De: Bruno Silva bemanuel...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br; 
Jean Domingues ejdom...@yahoo.com.br 
Enviadas: Quarta-feira, 19 de Setembro de 2012 18:10
Assunto: Re: [pgbr-geral] spclocation
 

Posso estar derivando/viajando, mas qual funcionalidade você está precisando? 
O comparação de bases? 
Enviado pelo meu Nexus
Em 19/09/2012 17:43, Jean Domingues ejdom...@yahoo.com.br escreveu:

Pessoal, 

não existe uma forma de eu contornar essa alteração que foi feita no catálogo 
do sistema? Algo como criar um campo no catálogo (se tiver falando besteira, 
me corrijam), em branco mesmo? Seria uma solução provisória, até que os 
desenvolvedores de ferramentas (EMS pra ser específico) atualizem os 
executáveis. Na verdade, estou refém do EMS Database Comparer para PostgreSQL.

Jean Domingues
___
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] spclocation

2012-09-19 Por tôpico Jean Domingues

Eu fiz uma nova instalação do servidor, compilei, configurei backup (por log). 
Pra reverter agora vai dar trabalho.


- Mensagem original -
 De: Osvaldo Kussama osvaldo.kuss...@gmail.com
 Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL 
 Brasileira pgbr-geral@listas.postgresql.org.br
 Cc: 
 Enviadas: Quarta-feira, 19 de Setembro de 2012 18:15
 Assunto: Re: [pgbr-geral] spclocation
 
 Em 19/09/12, Jean Dominguesejdom...@yahoo.com.br escreveu:
  Pessoal,
 
  não existe uma forma de eu contornar essa alteração que foi feita no
  catálogo do sistema? Algo como criar um campo no catálogo (se tiver falando
  besteira, me corrijam), em branco mesmo? Seria uma solução provisória, até
  que os desenvolvedores de ferramentas (EMS pra ser específico) atualizem os
  executáveis. Na verdade, estou refém do EMS Database Comparer para
  PostgreSQL.
 
 
 
 Por que não simplifica as coisas utilizando uma versão do PostgreSQL
 compatível com o software que é obrigado a utilizar?
 
 Osvaldo
 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Script de atualização

2012-09-18 Por tôpico Jean Domingues

Também uso o EMS Database Comparer porém, não esta suporte a versão 9.2. 
Alguem tem alguma alternativa?

Se tratando de estrutura do banco, estou utilizando a ferramenta EMS Database 
Comparer que faz a comparação entre duas bases e gera os scripts de 
atualização. Ela é paga, mas possui 30 dias de trial. Até agora tenho achado a 
ferramenta muito boa e tem me ajudado bastante aqui.


Espero ter ajudado!


Em 18 de setembro de 2012 11:17, Éverton Bueno Lima 
everton_bueno_l...@hotmail.com escreveu:

Bom dia a todos,
 
Estou precisando criar um script de atualização para postgresql, eu trabalho 
desenvolvendo em um banco de dados postgresql e quando o projeto ou a versão 
do sistema estiver pronta quero gerar um script de atualização do postgresql 
e encaminhar para os cliente e atualizar a estrutura da base dele igual a 
minha mantendo todos os dados do mesmo. Ainda não consegui encontrar uma 
solução se alguém puder ajudar agradeço desde já eu estou desenvolvendo minha 
aplicação em Delphi.
 
Att,
 
Éverton Bueno Lima
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Função com SQL Dinamico

2012-09-14 Por tôpico Jean Domingues

Ok... presumindo que vc queira que sejam *todas as empresas* quando o $1 
IS NULL, ou seja, o primeiro parâmetro seja nulo, então vc pode fazer o 
seguinte:




r_lista RECORD;
t_sql TEXT;

BEGIN

  t_sql := 'SELECT codigo, nome FROM tcliente WHERE ativo = 1';
  t_sql := t_sql || COALESCE(' AND empresa = ' || $1, '');

  FOR r_lista IN EXECUTE t_sql LOOP


Funcionou.


...
select codigo, nome from tcliente where ativo = 1 and empresa between 
coalesce($1,0) and coalesce($1,999)

...

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

Re: [pgbr-geral] Versão no 9.2 no Backports do Debian

2012-09-14 Por tôpico Jean Domingues

Jean,


Utilize o guia que você encontro neste endereço:  
http://blog.anantshri.info/howto-add-ppa-in-debian/  . É um script para que 
você passe a incluir repositórios ppa para o debian.


Após ter seguido o roteiro do blog, faça a inclusão propriamente dita do 
repositório para o postgres 9.2 


add-apt-repository ppa:pitti/postgresql


Pronto, agora é só dar apt-get update e os pacotes da versão 9.2 do postgres 
estarão disponíveis para serem instalados.


Espero ter contribuído.



Mauro, pra isso eu teria que ter o arquivo .deb gerado. (se é que eu entendi).
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Interpretar explain

com a execução caindo para 765 ms quando em cache. Me surpreende o fato de os 
join alterados não serem na tabela compras, e agora o plano usar o índice 
desejado em compras. Não caberia aqui alguma melhoria no algorítimo do 
otimizador?


O uso de índices com LEFT JOIN é um problema conhecido, não apenas no 
Postgres. 


Veja uma melhoria em relação a isto nos release notes do 9.1 em E.7.3.1.1. 
Performance: http://www.postgresql.org/docs/9.2/static/release-9-1.html


 

De qualquer forma, obrigado a todos pela ajuda. Foi esclarecedor pra mim e 
pra lista.




Cara, faz o que o Euler falou, manda o EXPLAIN ANALYZE. Vai permitir uma 
avaliação mais consistente. 


Algumas observações até aqui:


* Vale sempre a pena lembrar, antes de tudo rode um ANALYZE em todas as 
tabelas envolvidas. Sei que você já deve ter feito isso, mas eu mesmo esqueço 
de vez em quando...
* Muito LEFT JOIN em cascata é realmente um problema. Você pode trocar os mais 
caros por um UNION, onde você fazer um INNER JOIN em um e no outro no outro 
faz um WHERE NOT EXISTS.
* Você pode ter uma NFE sem ter uma compra e uma venda?

não. Tem que ter um ou outro.

* Uma informação relevante é o volume de registros entre as tabelas envolvidas;

sim... nfe: 600.000 - vendas: 520.000 - compras: 80.000

* Algumas tabelas aparecem mais de uma vez. Parecem ser tabelas pequenas, mas 
a modelagem ficou um pouco obscura para mim.


- Sim. Isso por que a tabela Terceiros recebe clientes, fornecedores, 
funcionarios, etc...

* A tabela COMPRAS tem mais de 10 índices, é isso mesmo? Verificou se todos 
estão sendo utilizados?

- Não verifiquei. Vou fazer isso. Mas de qualquer forma, isso interferiria 
apenas na performance de gravação, ne?

* Eu gosto um pouco de usar o EXPLAIN do PGADMIN III.  Em alguns momentos a 
visualização gráfica torna mais fácil de ver os gargalos dentro de um EXPLAIN 
muito grande.


Por enquanto é isso. Vamos aguardar o EXPLAIN ANALYZE, ok?


Segue abaixo o explain analyse. Porém a view foi corrigida, e melhorou em muito 
o desempenho, mudando apenas dois joins entre nfe e terceiros e nfe e 
naturezas_operacao (de left para join apenas). Feito isso, o plano passou a 
usar o índice de compras e vendas. Segue também abaixo o explain analyse sem a 
correção.

Corrigido:

  FROM nfe
       LEFT JOIN compras c ON c.id = nfe.id_compra
       LEFT JOIN vendas v ON v.id = nfe.id_venda
       JOIN terceiros t1 ON nfe.id_terceiro = t1.id
       JOIN naturezas_operacoes nop1 ON nfe.id_nat_operacao = nop1.id
       JOIN nfe_filas f ON f.id = nfe.id_fila
       LEFT JOIN terceiros t2 ON t2.id = nfe.id_func_emissao
       LEFT JOIN terceiros t3 ON t3.id = nfe.id_func_cancelamento
       LEFT JOIN romaneios r1 ON r1.id = v.id_romaneio
       LEFT JOIN romaneios r2 ON r2.id = c.id_romaneio_devolucao
       LEFT JOIN nfe_contingencia ctg ON ctg.id = nfe.id_contingencia;



QUERY PLAN
Sort  (cost=427805.46..428592.64 rows=314870 width=631) (actual 
time=1937.467..1937.469 rows=9 loops=1)
  Sort Key: nfe.numero_nf, nfe.id
  Sort Method: quicksort  Memory: 34kB
  -  Hash Left Join  (cost=83218.34..307649.71 rows=314870 width=512) (actual 
time=1221.194..1937.393 rows=9 loops=1)
        Hash Cond: (c.id_romaneio_devolucao = r2.id)
        -  Hash Left Join  (cost=81360.37..214851.30 rows=314870 width=500) 
(actual time=1207.026..1922.560 rows=9 loops=1)
              Hash Cond: (v.id_romaneio = r1.id)
              -  Hash Left Join  (cost=79502.40..205533.11 rows=314870 
width=488) (actual time=1192.595..1908.102 rows=9 loops=1)
                    Hash Cond: (nfe.id_contingencia = ctg.id)
                    -  Hash Left Join  (cost=79501.35..204351.30 rows=314870 
width=486) (actual time=1192.570..1908.061 rows=9 loops=1)
                          Hash Cond: (nfe.id_func_cancelamento = t3.id)
                          -  Hash Left Join  (cost=78700.38..24.89 
rows=314870 width=464) (actual time=1183.818..1899.292 rows=9 loops=1)
                                Hash Cond: (nfe.id_func_emissao = t2.id)
                                -  Hash Join  (cost=77899.40..193116.21 
rows=314870 width=442) (actual time=1174.509..1889.956 rows=9 loops=1)
                                      Hash Cond: (nfe.id_nat_operacao = 
nop1.id)
                                      -  Nested Loop  
(cost=77897.91..188785.26 rows=314870 width=418) (actual 
time=1174.481..1889.910 rows=9 loops=1)
                                            -  Seq Scan on nfe_filas f  
(cost=0.00..1.04 rows=1 width=11) (actual time=0.009..0.012 rows=1 loops=1)
                                                  Filter: (id = 1)
                                            -  Hash Join  
(cost=77897.91..185635.52 rows=314870 width=409) (actual 
time=1174.467..1889.880 rows=9 loops=1)
                                                  Hash Cond: (nfe.id_terceiro 
= t1.id)
                                                  -  Hash Left Join  
(cost=77096.93..178143.56 rows=314870 width=364)

Re: [pgbr-geral] Interpretar explain

Fabio, esquece a mensagem anterior... vou melhora-la mais tarde.




 De: Fábio Telles Rodriguez fabio.tel...@gmail.com
Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL Brasileira 
pgbr-geral@listas.postgresql.org.br 
Enviadas: Quinta-feira, 13 de Setembro de 2012 9:28
Assunto: Re: [pgbr-geral] Interpretar explain
 



com a execução caindo para 765 ms quando em cache. Me surpreende o fato de os 
join alterados não serem na tabela compras, e agora o plano usar o índice 
desejado em compras. Não caberia aqui alguma melhoria no algorítimo do 
otimizador?


O uso de índices com LEFT JOIN é um problema conhecido, não apenas no 
Postgres. 


Veja uma melhoria em relação a isto nos release notes do 9.1 em E.7.3.1.1. 
Performance: http://www.postgresql.org/docs/9.2/static/release-9-1.html


 

De qualquer forma, obrigado a todos pela ajuda. Foi esclarecedor pra mim e 
pra lista.




Cara, faz o que o Euler falou, manda o EXPLAIN ANALYZE. Vai permitir uma 
avaliação mais consistente. 


Algumas observações até aqui:


* Vale sempre a pena lembrar, antes de tudo rode um ANALYZE em todas as 
tabelas envolvidas. Sei que você já deve ter feito isso, mas eu mesmo esqueço 
de vez em quando...
* Muito LEFT JOIN em cascata é realmente um problema. Você pode trocar os mais 
caros por um UNION, onde você fazer um INNER JOIN em um e no outro no outro 
faz um WHERE NOT EXISTS.
* Você pode ter uma NFE sem ter uma compra e uma venda?
* Uma informação relevante é o volume de registros entre as tabelas envolvidas;
* Algumas tabelas aparecem mais de uma vez. Parecem ser tabelas pequenas, mas 
a modelagem ficou um pouco obscura para mim.
* A tabela COMPRAS tem mais de 10 índices, é isso mesmo? Verificou se todos 
estão sendo utilizados?
* Eu gosto um pouco de usar o EXPLAIN do PGADMIN III.  Em alguns momentos a 
visualização gráfica torna mais fácil de ver os gargalos dentro de um EXPLAIN 
muito grande.


Por enquanto é isso. Vamos aguardar o EXPLAIN ANALYZE, ok?


[]s


-- 
Atenciosamente,
Fábio Telles Rodriguezblog: http://http://tellesr.wordpress.com
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles


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

Re: [pgbr-geral] Interpretar explain

Fabio/Flávio/Marcone, 
me enganei quando disse que o plano havia passado a usar o indice 
correto. Reescrevi a query como manda o manual, mas deu na mesma. Nada elimina 
o fato de serem left joins. E realmente não tem como não ser. Veja como ficou a 
cláusula FROM da View (2). Ainda não sei como forçar os left joins a usarem a 
chave. Creio que meu problema seja o 

OR da where no select da view (1). Se o otimizador não consegue estabelecer 
índice pra tabela nfe, as demais vão entrar de gaiato, visto que a razao de 
registros é mais ou menos esta: registros venda + registros compra = registros 
nfe (+- isso)

Espero que eu tenha consegui explicar.


1) Select na view:

select * from view_fila_nfe where (id_empresa = 1) and
(id_fila = 1) and (status_retorno = '1') and 
(coalesce(email, '')  '') AND (((dh_cancelamento IS NULL) AND (dh_envio_email 
IS NULL) 
AND (nao_enviar_email = false))  OR ((dh_cancelamento IS NOT NULL) 
AND (dh_envio_email_canc IS NULL) AND (nao_enviar_email_canc = false))) order 
by numero_nf, id


2) Clausula from da View:

  FROM nfe
       JOIN nfe_filas f ON f.id = nfe.id_fila
       LEFT JOIN (compras c
       LEFT JOIN romaneios r2 ON r2.id = c.id_romaneio_devolucao) ON c.id 
= nfe.id_compra
       LEFT JOIN (vendas v LEFT JOIN romaneios r1 ON r1.id = v.id_romaneio) ON 
v.id = nfe.id_venda
       JOIN terceiros t1 ON nfe.id_terceiro = t1.id
       JOIN naturezas_operacoes nop1 ON nfe.id_nat_operacao = nop1.id
       LEFT JOIN terceiros t2 ON t2.id = nfe.id_func_emissao
       LEFT JOIN terceiros t3 ON t3.id = nfe.id_func_cancelamento
       LEFT JOIN nfe_contingencia ctg ON ctg.id = nfe.id_contingencia;

3) Plan:

QUERY PLAN
Sort  (cost=428000.27..428787.57 rows=314920 width=631) (actual 
time=1916.863..1916.865 rows=9 loops=1)
  Sort Key: nfe.numero_nf, nfe.id
  Sort Method: quicksort  Memory: 34kB
  -  Hash Left Join  (cost=83251.92..307825.09 rows=314920 width=512) (actual 
time=1193.258..1916.790 rows=9 loops=1)
        Hash Cond: (nfe.id_contingencia = ctg.id)
        -  Hash Left Join  (cost=83250.88..222401.98 rows=314920 width=510) 
(actual time=1193.045..1915.920 rows=9 loops=1)
              Hash Cond: (c.id_romaneio_devolucao = r2.id)
              -  Hash Left Join  (cost=81392.90..213830.23 rows=314920 
width=498) (actual time=1179.432..1902.286 rows=9 loops=1)
                    Hash Cond: (v.id_romaneio = r1.id)
                    -  Hash Left Join  (cost=79534.93..204510.86 rows=314920 
width=486) (actual time=1165.219..1888.047 rows=9 loops=1)
                          Hash Cond: (nfe.id_func_cancelamento = t3.id)
                          -  Hash Left Join  (cost=78728.84..200158.77 
rows=314920 width=464) (actual time=1156.528..1879.338 rows=9 loops=1)
                                Hash Cond: (nfe.id_func_emissao = t2.id)
                                -  Nested Loop  (cost=77922.75..193264.02 
rows=314920 width=442) (actual time=1147.371..1870.155 rows=9 loops=1)
                                      -  Seq Scan on nfe_filas f  
(cost=0.00..1.04 rows=1 width=11) (actual time=0.011..0.016 rows=1 loops=1)
                                            Filter: (id = 1)
                                      -  Hash Join  (cost=77922.75..190113.78 
rows=314920 width=433) (actual time=1147.356..1870.125 rows=9 loops=1)
                                            Hash Cond: (nfe.id_terceiro = 
t1.id)
                                            -  Hash Join  
(cost=77116.66..182615.64 rows=314920 width=388) (actual 
time=1137.210..1859.961 rows=9 loops=1)
                                                  Hash Cond: 
(nfe.id_nat_operacao = nop1.id)
                                                  -  Hash Left Join  
(cost=77115.17..178284.00 rows=314920 width=364) (actual 
time=1137.173..1859.900 rows=9 loops=1)
                                                        Hash Cond: 
(nfe.id_compra = c.id)
                                                        -  Hash Right Join  
(cost=70981.04..167401.37 rows=314920 width=346) (actual 
time=1034.179..1756.879 rows=9 loops=1)
                                                              Hash Cond: (v.id 
= nfe.id_venda)
                                                              -  Seq Scan on 
vendas v  (cost=0.00..63304.69 rows=751569 width=27) (actual 
time=0.005..722.987 rows=749100 loops=1)
                                                              -  Hash  
(cost=53512.54..53512.54 rows=314920 width=327) (actual time=639.931..639.931 
rows=9 loops=1)
                                                                    Buckets: 
16384  Batches: 4  Memory Usage: 2kB
                                                                    -  Seq 
Scan on nfe  (cost=0.00..53512.54 rows=314920 width=327) (actual 
time=560.724..560.831 rows=9 loops=1)
                                                                          
Filter: dh_cancelamento IS NULL) AND (dh_envio_email IS NULL) AND (NOT 
nao_enviar_email))

[pgbr-geral] Versão no 9.2 no Backports do Debian

Alguem sabe quem posta o instalador no repositorio do debian (backports)? Estou 
aguardando pra fazer atualização do servidor. E pelo apt é mais facil. (ou 
ainda pelo binario .deb).

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

Re: [pgbr-geral] Versão no 9.2 no Backports do Debian

Bruno, deve resolver sim. Mas nunca fiz, vou ter que aprender. O pacote .deb já 
faz a instalação nas pastas certas, gera script de carga, etc. Não sei se esse 
ai faz. Se não tiver outra opção, o jeito vai ser aprender. A preguiça é um 
problema. hehehehe.

 http://www.enterprisedb.com/products-services-training/pgdownload

 Não resolve?
 Eu prefiro compilar
 
 Bruno E. A. Silva.
 Analista de Sistemas.
 
 
 2012/9/13 Jean Domingues ejdom...@yahoo.com.br:
  Alguem sabe quem posta o instalador no repositorio do debian (backports)? 
 Estou aguardando pra fazer atualização do servidor. E pelo apt é mais facil. 
 (ou 
 ainda pelo binario .deb).
 
  Grato,
  Jean Domingues.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Interpretar explain

Pessoal,

só postando na lista a conclusão a que cheguei pela thread. Como eu suspeitei, 
o problema é que os filtros (where) para a tabela principal da view (nfe) não 
eram suficientes para indicar um índice. Assim, como teria que se verificar 
todas as linhas mesmo, não se usava índice pra nada. Resumi entao toda a where 
para um unico campo em nfe, que alimento via trigger, que me diz se o registro 
é alvo ou nao (se tem email a ser enviado). Dai criei um indice neste campo. E 
segue abaixo o resultado. Percebam que agora o otimizado usa os indices de 
chave primária nas maiores tabelas. Fábio, quanto ao UNION, creio que 
resolvesse também, apesar de que ainda assim, o otimizador não usaria um indice 
em nfe, pois testei explanar o select apenas nesta tabela, e o resultado foi 
seqscan. Bom, mais uma vez, obrigado a todos. Creio que foi esclarecedor pra 
todos.

1) select na view

select * from view_fila_nfe x
where x.id_empresa = 1
and x.email_pendente


2) explain

QUERY PLAN
Nested Loop Left Join  (cost=0.00..70.49 rows=1 width=737)
  Join Filter: (ctg.id = nfe.id_contingencia)
  -  Nested Loop Left Join  (cost=0.00..69.18 rows=1 width=729)
        -  Nested Loop Left Join  (cost=0.00..60.90 rows=1 width=717)
              -  Nested Loop Left Join  (cost=0.00..52.61 rows=1 width=705)
                    -  Nested Loop Left Join  (cost=0.00..44.33 rows=1 
width=683)
                          -  Nested Loop  (cost=0.00..36.05 rows=1 width=661)
                                Join Filter: (nfe.id_nat_operacao = nop1.id)
                                -  Nested Loop  (cost=0.00..34.56 rows=1 
width=487)
                                      -  Nested Loop Left Join  
(cost=0.00..26.27 rows=1 width=442)
                                            -  Nested Loop  (cost=0.00..17.81 
rows=1 width=423)
                                                  Join Filter: (nfe.id_fila = 
f.id)
                                                  -  Nested Loop Left Join  
(cost=0.00..16.76 rows=1 width=345)
                                                        -  Index Scan using 
nfe_idx14 on nfe  (cost=0.00..8.47 rows=1 width=327)
                                                              Index Cond: 
((id_empresa = 1) AND (email_pendente = true))
                                                              Filter: 
email_pendente
                                                        -  Index Scan using 
compras_pkey on compras c  (cost=0.00..8.29 rows=1 width=26)
                                                              Index Cond: (id = 
nfe.id_compra)
                                                  -  Seq Scan on nfe_filas f  
(cost=0.00..1.02 rows=2 width=80)
                                            -  Index Scan using vendas_pkey on 
vendas v  (cost=0.00..8.45 rows=1 width=27)
                                                  Index Cond: (id = 
nfe.id_venda)
                                      -  Index Scan using terceiros_pkey on 
terceiros t1  (cost=0.00..8.27 rows=1 width=49)
                                            Index Cond: (id = nfe.id_terceiro)
                                -  Seq Scan on naturezas_operacoes nop1  
(cost=0.00..1.22 rows=22 width=182)
                          -  Index Scan using terceiros_pkey on terceiros t2  
(cost=0.00..8.27 rows=1 width=30)
                                Index Cond: (id = nfe.id_func_emissao)
                    -  Index Scan using terceiros_pkey on terceiros t3  
(cost=0.00..8.27 rows=1 width=30)
                          Index Cond: (id = nfe.id_func_cancelamento)
              -  Index Scan using romaneios_pkey on romaneios r1  
(cost=0.00..8.27 rows=1 width=20)
                    Index Cond: (id = v.id_romaneio)
        -  Index Scan using romaneios_pkey on romaneios r2  (cost=0.00..8.27 
rows=1 width=20)
              Index Cond: (id = c.id_romaneio_devolucao)
  -  Seq Scan on nfe_contingencia ctg  (cost=0.00..1.02 rows=2 width=12)

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

Re: [pgbr-geral] Versão no 9.2 no Backports do Debian