Re: [pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

2016-09-02 Por tôpico MIGUEL JOSE DE LIMA 
>> Por algum motivo a Oracle mudou o nome da opção TCP_KEEPALIVE ou não
>> suporta lê-la? Isso já foi reportado na lista -bugs [1] mas ninguém se
>> importou em corrigir ainda. Isso não é algo preocupante a não ser o fato
>> de encher o seu log com essas mensagens. Por curiosidade, o postgres foi
>> compilado na própria máquina ou você instalou algum pacote?

Foi compilado na própria máquina.

Obrigado, sendo assim fico mais tranquilo que não é um erro mais grave.

Em 2 de setembro de 2016 19:15, Euler Taveira 
escreveu:

> On 02-09-2016 18:24, MIGUEL JOSE DE LIMA wrote:
> > LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
> >
> Por algum motivo a Oracle mudou o nome da opção TCP_KEEPALIVE ou não
> suporta lê-la? Isso já foi reportado na lista -bugs [1] mas ninguém se
> importou em corrigir ainda. Isso não é algo preocupante a não ser o fato
> de encher o seu log com essas mensagens. Por curiosidade, o postgres foi
> compilado na própria máquina ou você instalou algum pacote?
>
> Os parâmetros no PostgreSQL não vão fazer diferença se no sistema
> operacional eles não puderem ser aplicados.
>
>
> [1]
> https://www.postgresql.org/message-id/CAJgtxT6QL0_Gt+
> TkSDw=q1=yvjkt73fosrtstcu5hy+-sxn...@mail.gmail.com
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

2016-09-02 Por tôpico Euler Taveira 
On 02-09-2016 18:24, MIGUEL JOSE DE LIMA wrote:
> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
> 
Por algum motivo a Oracle mudou o nome da opção TCP_KEEPALIVE ou não
suporta lê-la? Isso já foi reportado na lista -bugs [1] mas ninguém se
importou em corrigir ainda. Isso não é algo preocupante a não ser o fato
de encher o seu log com essas mensagens. Por curiosidade, o postgres foi
compilado na própria máquina ou você instalou algum pacote?

Os parâmetros no PostgreSQL não vão fazer diferença se no sistema
operacional eles não puderem ser aplicados.


[1]
https://www.postgresql.org/message-id/CAJgtxT6QL0_Gt+TkSDw=q1=yvjkt73fosrtstcu5hy+-sxn...@mail.gmail.com


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

2016-09-02 Por tôpico MIGUEL JOSE DE LIMA 
2016-09-02 18:44 GMT-03:00 Flavio Henrique Araque Gurgel :

>
>
> Em sex, 2 de set de 2016 23:24, MIGUEL JOSE DE LIMA <
> mig...@inlocsistemas.com.br> escreveu:
>
>> Alguém sabe me dizer porque recebo erro no log do server fazendo
>> referência ao TCP_KEEPALIVE:
>> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>>
>> Trabalho com SPARC SOLARIS 10 e Postgresql 9.5.4 (64bits)
>>
>> Parte do log do server:
>> 
>> 
>> --
>>
>> ERROR:  syntax error at end of input at character 184
>> STATEMENT:  SELECT "pon_unidade_supervisao".*, "cor_unidade".*
>> FROM "pon_unidade_supervisao"
>> INNER JOIN "corporativo"."cor_unidade" ON "unu_id_unidade" =
>> "uni_id_unidade"
>> WHERE "unu_id_pessoa" =
>> WARNING:  there is no transaction in progress
>> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>> STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
>> 'track_counts')
>> ERROR:  permission denied for relation pon_configuracao
>> STATEMENT:  SELECT count(*) AS rows FROM ONLY ponto.pon_configuracao
>> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>> STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
>> 'track_counts')
>> 
>> 
>> 
>>
>> Obs.: O parâmetros de TCP_... no postgresql.conf estão no padrão default!
>>  # - TCP Keepalives -
>>  #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in
>> seconds;
>>  #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in
>> seconds;
>>  #tcp_keepalives_count = 0   # TCP_KEEPCNT;
>>
>>
>> Obrigado.
>>
>
> >>Solaris 10 não suporta keepalives.
> >>Por algum motivo, foi setado no seu servidor, verifique scripts de
> inicialização e se está olhando o bom conf.
>

Gurgel obrigado,
mas sinceramente não entendi o q vc quis dizer com "...está olhando o bom
conf" rsrsrs.
O postgresql.conf está com as configurações padrões como citei acima.
Não estou entendendo, tem alguma configuração no S.O do server?
Conforme está no manual (18.3.1), deveria ser zero, como está, para
sistemas que não suportam keepalive.

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

Re: [pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
Em sex, 2 de set de 2016 23:24, MIGUEL JOSE DE LIMA <
mig...@inlocsistemas.com.br> escreveu:

> Alguém sabe me dizer porque recebo erro no log do server fazendo
> referência ao TCP_KEEPALIVE:
> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>
> Trabalho com SPARC SOLARIS 10 e Postgresql 9.5.4 (64bits)
>
> Parte do log do server:
>
> --
>
> ERROR:  syntax error at end of input at character 184
> STATEMENT:  SELECT "pon_unidade_supervisao".*, "cor_unidade".*
> FROM "pon_unidade_supervisao"
> INNER JOIN "corporativo"."cor_unidade" ON "unu_id_unidade" =
> "uni_id_unidade"
> WHERE "unu_id_pessoa" =
> WARNING:  there is no transaction in progress
> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
> STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
> 'track_counts')
> ERROR:  permission denied for relation pon_configuracao
> STATEMENT:  SELECT count(*) AS rows FROM ONLY ponto.pon_configuracao
> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
> STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
> 'track_counts')
>
> 
>
> Obs.: O parâmetros de TCP_... no postgresql.conf estão no padrão default!
>  # - TCP Keepalives -
>  #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in
> seconds;
>  #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in
> seconds;
>  #tcp_keepalives_count = 0   # TCP_KEEPCNT;
>
>
> Obrigado.
>

Solaris 10 não suporta keepalives.
Por algum motivo, foi setado no seu servidor, verifique scripts de
inicialização e se está olhando o bom conf.

[]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] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

2016-09-02 Por tôpico MIGUEL JOSE DE LIMA 
Alguém sabe me dizer porque recebo erro no log do server fazendo referência
ao TCP_KEEPALIVE:
LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol

Trabalho com SPARC SOLARIS 10 e Postgresql 9.5.4 (64bits)

Parte do log do server:
--

ERROR:  syntax error at end of input at character 184
STATEMENT:  SELECT "pon_unidade_supervisao".*, "cor_unidade".*
FROM "pon_unidade_supervisao"
INNER JOIN "corporativo"."cor_unidade" ON "unu_id_unidade" =
"uni_id_unidade"
WHERE "unu_id_pessoa" =
WARNING:  there is no transaction in progress
LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
'track_counts')
ERROR:  permission denied for relation pon_configuracao
STATEMENT:  SELECT count(*) AS rows FROM ONLY ponto.pon_configuracao
LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
'track_counts')


Obs.: O parâmetros de TCP_... no postgresql.conf estão no padrão default!
 # - TCP Keepalives -
 #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in seconds;
 #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in
seconds;
 #tcp_keepalives_count = 0   # TCP_KEEPCNT;


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

Re: [pgbr-geral] Ponto de Controle primário inválido

2016-09-02 Por tôpico Euler Taveira 
On 02-09-2016 16:30, Bruno Felipe wrote:
> Alguém sabe o que pode ser ou como conseguir recuperar essa base?
> 
Aparentemente o WAL está corrompido. Você pode dar detalhes? Versão? É
um standby? Parada abrupta? Configuração [1]?

Você faz backup físico? Use-o.

PS> antes de qualquer tentativa de recuperação, copie todo cluster para
um lugar seguro.


[1] https://gist.github.com/eulerto/450501d8ef00404e665b46a2f2a6e8e2


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Ponto de Controle primário inválido

2016-09-02 Por tôpico Bruno Felipe 
Boa tarde pessoal,
to tentando subir um banco de dados a partir da pasta dada pelo comando

pg_ctl start -D "C:\data" -w

Porém sem sucesso, ele da esse erro no log:

2016-09-02 15:52:02 BRT LOG:  sistema de banco de dados foi desligado em
2016-08-31 12:02:24 BRT
2016-09-02 15:52:02 BRT LOG:  registro com tamanho zero em 1/B98A01B0
2016-09-02 15:52:02 BRT LOG:  registro do ponto de controle primário é
inválido
2016-09-02 15:52:02 BRT LOG:  registro com tamanho zero em 1/B98A0150
2016-09-02 15:52:02 BRT LOG:  registro do ponto de controle secundário é
inválido
2016-09-02 15:52:02 BRT PÂNICO:  não pôde localizar registro do ponto de
controle válido
2016-09-02 15:52:02 BRT LOG:  processo de inicialização (PID 2456) terminou
com código de retorno 3
2016-09-02 15:52:02 BRT LOG:  interrompendo inicialização porque o processo
de inicialização falhou

Alguém sabe o que pode ser ou como conseguir recuperar essa base?

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

Re: [pgbr-geral] quando usar vacuum full analyze

2016-09-02 Por tôpico Euler Taveira 
On 01-09-2016 08:32, Luiz Henrique wrote:
> Segue anexo os planos da consulta. Obrigado pela ajuda
> 
Evite top-posting.

Faltou alguns dados: a consulta e os parâmetros [1]. Além disso, os
parâmetros são os mesmos nas duas máquinas? As versões são as mesmas
(digo, 9.1.23 e 9.1.23)? Você executou um ANALYZE em todas as tabelas da
consulta antes do EXPLAIN ANALYZE?

Em produção o que está levando bastante tempo é a junção abaixo (quase
70% do tempo).

[cortando partes do plano]

Hash Join  (actual time=2.298..90.849 rows=2027 loops=998)
  Hash Cond: (pf.id = p.id_pessoa)
  ->  Seq Scan on pessoa_fisica pf  (actual time=0.003..27.918
rows=303774 loops=998)
  ->  Hash (actual time=4.164..4.164 rows=3447 loops=1)
Buckets: 1024  Batches: 1  Memory Usage: 367kB
->  Seq Scan on parceiro p  (actual time=0.006..2.956 rows=3447
loops=1)

Há índices em pf.id e p.id_pessoa?

O mesmo ocorre com outra parte da consulta só que em pessoa_juridica.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 12:42 GMT-03:00 Gustavo :
>
> eu conheço SQL só que estou aprendendo postgres

O SQL do PostgreSQL é bem mais rico do que o que se costuma usar em
outros SGBDs.


> eu até ja fiz umas coisas em PL   mais fiquei na duvida quando vi em artigo 
> falando sobre o SQL

Mas que dúvida, especificamente?  E o que dizia esse artigo?


> mais a grosso modo, a PL são para os casos mais complexos do postgres ou 
> quando quer fazer algo em outra linguagem

Mais para poder escolher a linguagem.  O SQL em si resolve muita coisa
declarativamente.  O procedural não é tão mais poderoso que o
declarativo quanto pode parecer à primeira vista.


> e a SQL seria mais para queries de consulta onde não há necessidade de algo 
> mais complexo...

Não, SQL faz praticamente tudo, principalmente quando usado como uma
sublinguagem de dados.  Por exemplo, foi concebido inicialmente para
usar junto com Cobol.


> pelo que vi o PL usa mais recuso do servidor... por isso a preocupação..

Sim, mas essa é a natureza da programação procedural.  Por isso, entre
outras razões, é bom sempre pensar primeiro declarativamente, e só
passar para o procedural quando não tiver outro jeito.

E as PLs, embora consumam recursos do servidor, ainda são mais
eficientes, por rodarem no SGBD, que o SQL como sublinguagem de dados
num processo externo; por exempo, PL/Java tenderá a ser mais eficiente
que SQL dentro do Java fora do SGBD.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Recuperação rápida com preservação de transações?

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 11:48 GMT-03:00 Flavio Henrique Araque Gurgel :
>
> Quem sabe uma PgConzinha com um belo caso de uso?

Dentro!  Depois de seis anos e meio de burocracia, estou muito a fim
de voltar à vida (técnica).


> A transação preparada sobrevive a falhas do serviço de banco de dados ou do
> servidor. Uma réplica (ou mesmo o antigo mestre reinicializado) guarda a
> transação no estado em que ela estava. Exemplo :
> Servidor principal:
> BEGIN;
> PREPARE TRANSACTION  xxx; --xxx é seu identificador
> INSERT...
> UPDATE...
> DELETE...
> --CRASH--
>
> Sobe o servidor secundário (previamente em replicação síncrona):
> COMMIT PREPARED xxx;
> Continua a vida.

Bonito.


> Note que esta implementação tem várias nuances, por exemplo, existe o risco
> de "esquecer" a transação aberta e isso tem custos altos (como tuplas que
> não são recuperadas pelo autovacuum, bloqueios que não são liberados, etc),
> logo, a aplicação tem que ser bem escrita.

A aplicação é nossa, então isso não seria problema, em princípio.


>> > já garante o requisito se em replicação síncrona.
>>
>> Quiseste dizer sem replicação síncrona?
>
> Não, a replicação *tem de ser síncrona* senão você corre o risco de não ter
> algo replicado a tempo e o usuário não poderá continuar o que estava
> fazendo.

Agora entendi.  Não consegui entender a tua frase, achei que fosse
erro de digitação (em tempos de teclados de celular…)


> Isso tem um impacto no desempenho, evidentemente.

Provavelmente é irrelevante.  Nossas maiores bases são muito pequenas,
e essa é minúscula.


>> > Você precisará de algo pra fazer o fail-over automático, algumas
>> > soluções
>> > que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
>> > https://github.com/zalando/patroni
>>
>> Pesquisaremos, obrigado!

Caramba, etcd e CoreOS… estou muito desatualizado!  Nem sei por onde começar aí.


> Calma lá, analise todos os requisitos, até aqui você nos deu um pedaço do
> bolo. Possível, digamos que é, claro. Mas são muitas variáveis, acho que
> cabe um estudo e um POC bem caprichado (o governo adora POC ;) ) e uma boa
> consultoria seria de bom tom, mas isso você sabe e já até falou.

Os colegas que têm 'todos os requisitos' estão em cópia, espero que
entrem na comunidade.  Mas de qualquer maneira conversaremos
internamente.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Gustavo 
eu conheço SQL só que estou aprendendo postgres
por isso essa duvida entre os 2
eu até ja fiz umas coisas em PL   mais fiquei na duvida quando vi em artigo
falando sobre o SQL

mais a grosso modo, a PL são para os casos mais complexos do postgres ou
quando quer fazer algo em outra linguagem

e a SQL seria mais para queries de consulta onde não há necessidade de algo
mais complexo...
pelo que vi o PL usa mais recuso do servidor... por isso a preocupação..

obrigado pela ajuda

[]s
Gustavo Castilho
ᐧ

Em 2 de setembro de 2016 12:35, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-09-02 12:32 GMT-03:00 Gustavo :
> >
> > Então para obter uma simples lista de produtos..  posso usar o language
> SQL ??
>
> Deve.
>
> Faça o seguinte.  Pegue o Chris Date, _Introdução a sistemas de bancos
> de dados_.  E leia.
>
> Se precisar de algo mais rápido, pegue algum tutorial de SQL.  Para
> brincar, tem bases de amostra para testes no PostgreSQL.
>
> Depois que já se tiver familiarizado com SQL escolha alguma PL e brinque.
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 11:58 GMT-03:00 Flavio Henrique Araque Gurgel :
>> o Oracle.  Para portabilidade e padronização, prefira o PL/pgPSM; mas
>> há várias outras PLs a gosto, como PL/Python, PL/Java, PL/Ruby…
>>
> Desculpe intervir

Não precisa se desculpar, tuas intervenções são sempre adequadas e,
freqüentemente, essenciais.


> mas, até onde sei, a proposta de integrar PL/pgPSM ao
> PostgreSQL não andou muito desde a versão 9.3 quando foi proposta por alguém
> que não lembro.
> A página da versão externa está às moscas no pgFoundry e em fase alfa.
> Posso estar errado, perdi algum bonde?

Não está errado.  É o padrão SQL, mas na prática PL/Java e PL/pgSQL
podem ser mais portáveis.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 12:27 GMT-03:00 Sebastian Webber :
>
> Em 2 de setembro de 2016 12:02, Gustavo 
> escreveu:
>>
>> mais para eu fazer uma simples validação de dados BEFORE antes da
>> gravaçao...  faço em SQL ou PLPgSQL ?
>> é um simples if para saber se o valor é valido ou não...
>
> Nesse caso, utilize plpgsql. Veja a doc[1] com exemplos e maiores detalhes.

Não, prefira o CHECK VALIDATE.   Validações em PLs é só para os casos
(não tão freqüentes na prática) em que as restrições de integridade
declarativas não são suficientes.  Como aliás a resposta do Gurgel já
indicou.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 12:32 GMT-03:00 Gustavo :
>
> Então para obter uma simples lista de produtos..  posso usar o language SQL ??

Deve.

Faça o seguinte.  Pegue o Chris Date, _Introdução a sistemas de bancos
de dados_.  E leia.

Se precisar de algo mais rápido, pegue algum tutorial de SQL.  Para
brincar, tem bases de amostra para testes no PostgreSQL.

Depois que já se tiver familiarizado com SQL escolha alguma PL e brinque.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Gustavo 
Então para obter uma simples lista de produtos..  posso usar o language SQL
??

[]s
Gustavo Castilho
ᐧ

Em 2 de setembro de 2016 12:27, Sebastian Webber 
escreveu:

>
>
> Em 2 de setembro de 2016 12:02, Gustavo 
> escreveu:
>
>> mais para eu fazer uma simples validação de dados BEFORE antes da
>> gravaçao...  faço em SQL ou PLPgSQL ?
>> é um simples if para saber se o valor é valido ou não...
>>
>>
> Nesse caso, utilize plpgsql. Veja a doc[1] com exemplos e maiores detalhes.
>
> [1] https://www.postgresql.org/docs/current/static/plpgsql-trigger.html
>
>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
:

> mais para eu fazer uma simples validação de dados BEFORE antes da
> gravaçao...  faço em SQL ou PLPgSQL ?
> é um simples if para saber se o valor é valido ou não...
>

Por favor, evite o top-post.

Qual é a validação que quer fazer, um check não resolveria?
Se for complicado e você fará com triggers, você terá de escrever uma
função para fazer a sua validação, você terá de fazer em linguagem
procedural.

Note que sua pergunta inicial está longe do seu real problema.

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

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Sebastian Webber 
Em 2 de setembro de 2016 12:02, Gustavo 
escreveu:

> mais para eu fazer uma simples validação de dados BEFORE antes da
> gravaçao...  faço em SQL ou PLPgSQL ?
> é um simples if para saber se o valor é valido ou não...
>
>
Nesse caso, utilize plpgsql. Veja a doc[1] com exemplos e maiores detalhes.

[1] https://www.postgresql.org/docs/current/static/plpgsql-trigger.html


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

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Gustavo 
mais para eu fazer uma simples validação de dados BEFORE antes da
gravaçao...  faço em SQL ou PLPgSQL ?
é um simples if para saber se o valor é valido ou não...

[]s
Gustavo Castilho
ᐧ

Em 2 de setembro de 2016 11:58, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> o Oracle.  Para portabilidade e padronização, prefira o PL/pgPSM; mas
>> há várias outras PLs a gosto, como PL/Python, PL/Java, PL/Ruby…
>>
>> Desculpe intervir mas, até onde sei, a proposta de integrar PL/pgPSM ao
> PostgreSQL não andou muito desde a versão 9.3 quando foi proposta por
> alguém que não lembro.
> A página da versão externa está às moscas no pgFoundry e em fase alfa.
> Posso estar errado, perdi algum bonde?
>
> []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] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
>
> o Oracle.  Para portabilidade e padronização, prefira o PL/pgPSM; mas
> há várias outras PLs a gosto, como PL/Python, PL/Java, PL/Ruby…
>
> Desculpe intervir mas, até onde sei, a proposta de integrar PL/pgPSM ao
PostgreSQL não andou muito desde a versão 9.3 quando foi proposta por
alguém que não lembro.
A página da versão externa está às moscas no pgFoundry e em fase alfa.
Posso estar errado, perdi algum bonde?

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

Re: [pgbr-geral] max_worker_processes

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
> Pessoal,
>
> Existe alguma regra pra configurar o max_worker_processes?
>

Você está usando algum módulo carregável?
Senão, não há o que se preocupar aí. É só a quantidade máxima de processos
de retaguarda para módulos externos (exemplo, replicação lógica).

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

Re: [pgbr-geral] Recuperação rápida com preservação de transações?

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
>
> > Que desafio bonito!
>
> Sendo para o setor público, acho que fica lindo.  Pode virar um caso
> para apresentação; apesar de ser pequeno, é muito crítico (para o
> Brasil!) e será muito visível.
>

Quem sabe uma PgConzinha com um belo caso de uso?


>
> >> Temos um sistema onde o usuário espera não ter de reiniciar uma
> >> transação mesmo com falha de um servidor, desde que outro possa
> >> automaticamente continuá-la num intervalo de até quinze segundos.
> >> Quais seriam os componentes mais indicados para essa situação em
> >> PostgreSQL hoje?  PostgresXL, PostgresXC, pg_pool?  Perdoem a
> >> ignorância, estou muito enferrujado mesmo.
> >
> > Eu vejo algo mais como transações preparadas e replicação ordinária
>
> Poderia explicar melhor?  Estou muito enferrujado mesmo, e o colega
> não é familiarizado com PostgreSQL.  Pelo que estou entendendo, as
> transações preparadas (efetivação em duas fases) serviriam para que a
> réplica entre no ar como principal com a transação efetivada, confere?
>

A transação preparada sobrevive a falhas do serviço de banco de dados ou do
servidor. Uma réplica (ou mesmo o antigo mestre reinicializado) guarda a
transação no estado em que ela estava. Exemplo :
Servidor principal:
BEGIN;
PREPARE TRANSACTION  xxx; --xxx é seu identificador
INSERT...
UPDATE...
DELETE...
--CRASH--

Sobe o servidor secundário (previamente em replicação síncrona):
COMMIT PREPARED xxx;
Continua a vida.

Note que esta implementação tem várias nuances, por exemplo, existe o risco
de "esquecer" a transação aberta e isso tem custos altos (como tuplas que
não são recuperadas pelo autovacuum, bloqueios que não são liberados, etc),
logo, a aplicação tem que ser bem escrita.
Tabelas temporárias ou não-logadas não podem participar desse tipo de
transação.

>
> > já garante o requisito se em replicação síncrona.
>
> Quiseste dizer sem replicação síncrona?
>

Não, a replicação *tem de ser síncrona* senão você corre o risco de não ter
algo replicado a tempo e o usuário não poderá continuar o que estava
fazendo. Isso tem um impacto no desempenho, evidentemente.


> > Você precisará de algo pra fazer o fail-over automático, algumas soluções
> > que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
> > https://github.com/zalando/patroni
>
> Pesquisaremos, obrigado!
>
>
> > Acho que o conceito pode ser provado sim.
>
> Não sabes como isso me deixa feliz!
>
> Calma lá, analise todos os requisitos, até aqui você nos deu um pedaço do
bolo. Possível, digamos que é, claro. Mas são muitas variáveis, acho que
cabe um estudo e um POC bem caprichado (o governo adora POC ;) ) e uma boa
consultoria seria de bom tom, mas isso você sabe e já até falou.

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

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 11:20 GMT-03:00 Gustavo :
>
> duvidas e as diferenças do plpgsql e sql

SQL: linguagem declarativa de manipulação de estruturas e dados.

PL/pgSQL: linguagem procedural para programação, usando SQL.


> 1. Alguém pode me dar um exemplo pratico em que momento utilizar o plpgsql e 
> o sql ?

SQL usas interativamente ou dentro de programas de outras linguagens,
como Python, Ruby…

PL/pgSQL é um derivado de Ada que é a linguagem de programação padrão
para aplicativos e procedimentos armazenados no PostgreSQL, espelhando
o Oracle.  Para portabilidade e padronização, prefira o PL/pgPSM; mas
há várias outras PLs a gosto, como PL/Python, PL/Java, PL/Ruby…


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

2016-09-02 Por tôpico Gustavo 
olá senhores

duvidas e as diferenças do plpgsql e sql
se alguém puder me ajudar a esclarecer essa duvida

1. Alguém pode me dar um exemplo pratico em que momento utilizar o *plpgsql*
e o *sql ?*

*2 .Quais as vantagens para a utilização de 1 deles ?*

*li alguns artigos..  mais esta dificil ter uma definição a respeito desse
assunto*

grato pelo ajuda
Gustavo
ᐧ
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Recuperação rápida com preservação de transações?

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-02 10:54 GMT-03:00 Flavio Henrique Araque Gurgel :
>
>> Um colega me colocou um requisito para viabilizar uma migração de
>> Oracle com retrabalho e investimentos mínimos.
>
> Que desafio bonito!

Sendo para o setor público, acho que fica lindo.  Pode virar um caso
para apresentação; apesar de ser pequeno, é muito crítico (para o
Brasil!) e será muito visível.


>> Temos um sistema onde o usuário espera não ter de reiniciar uma
>> transação mesmo com falha de um servidor, desde que outro possa
>> automaticamente continuá-la num intervalo de até quinze segundos.
>> Quais seriam os componentes mais indicados para essa situação em
>> PostgreSQL hoje?  PostgresXL, PostgresXC, pg_pool?  Perdoem a
>> ignorância, estou muito enferrujado mesmo.
>
> Eu vejo algo mais como transações preparadas e replicação ordinária

Poderia explicar melhor?  Estou muito enferrujado mesmo, e o colega
não é familiarizado com PostgreSQL.  Pelo que estou entendendo, as
transações preparadas (efetivação em duas fases) serviriam para que a
réplica entre no ar como principal com a transação efetivada, confere?


> já garante o requisito se em replicação síncrona.

Quiseste dizer sem replicação síncrona?


> Você precisará de algo pra fazer o fail-over automático, algumas soluções
> que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
> https://github.com/zalando/patroni

Pesquisaremos, obrigado!


> Acho que o conceito pode ser provado sim.

Não sabes como isso me deixa feliz!


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] max_worker_processes

2016-09-02 Por tôpico Luiz Carlos L. Nogueira Jr. 
Pessoal,

Existe alguma regra pra configurar o max_worker_processes?

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

Re: [pgbr-geral] Recuperação rápida com preservação de transações?

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
>
> Um colega me colocou um requisito para viabilizar uma migração de
> Oracle com retrabalho e investimentos mínimos.
>

Que desafio bonito!


>
> Temos um sistema onde o usuário espera não ter de reiniciar uma
> transação mesmo com falha de um servidor, desde que outro possa
> automaticamente continuá-la num intervalo de até quinze segundos.
> Quais seriam os componentes mais indicados para essa situação em
> PostgreSQL hoje?  PostgresXL, PostgresXC, pg_pool?  Perdoem a
> ignorância, estou muito enferrujado mesmo.
>

Eu vejo algo mais como transações preparadas e replicação ordinária, já
garante o requisito se em replicação síncrona.
Você precisará de algo pra fazer o fail-over automático, algumas soluções
que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
https://github.com/zalando/patroni


>
> O nosso custo de Oracle para esse sistema é muito baixo hoje; o motivo
> da migração é se livrar da trabalheira que o Oracle produto, e a
> Oracle empresa, dão.  Mas há uma oportunidade de negócio porque
> provavelmente contrataremos suporte para o PostgreSQL, caso consigamos
> provar o conceito.
>

Acho que o conceito pode ser provado sim.

[]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] Recuperação rápida com preservação de transações?

2016-09-02 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
Bom dia!

Um colega me colocou um requisito para viabilizar uma migração de
Oracle com retrabalho e investimentos mínimos.

Temos um sistema onde o usuário espera não ter de reiniciar uma
transação mesmo com falha de um servidor, desde que outro possa
automaticamente continuá-la num intervalo de até quinze segundos.
Quais seriam os componentes mais indicados para essa situação em
PostgreSQL hoje?  PostgresXL, PostgresXC, pg_pool?  Perdoem a
ignorância, estou muito enferrujado mesmo.

O nosso custo de Oracle para esse sistema é muito baixo hoje; o motivo
da migração é se livrar da trabalheira que o Oracle produto, e a
Oracle empresa, dão.  Mas há uma oportunidade de negócio porque
provavelmente contrataremos suporte para o PostgreSQL, caso consigamos
provar o conceito.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Validar valor do work_mem

2016-09-02 Por tôpico Alessandro Lima 
>>Vê sim.
>>Exemplo, quando aparece algo como:
>>  Sort Method: quicksort  Memory: 25kB

Agora consegui ver o Sort Method, é que tinha testado com order by em um
indice.

Fiz um teste aumentando o tamanho da consulta, para ver até onde era usado
o work_mem:
-com limit 56000, o Sort Method utiliza cerca de 17MB "Memory" e é
executado em 1,2s
-com limit 57000, o Sort Method utiliza cerca de 683MB "Merge Disk" e é
executado em 9s
considerando meu work_mem = 32MB, não deveria utilizar o disco apenas
depois de 32MB?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Validar valor do work_mem

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
 escreveu:

> >>EXPLAIN (analyze, timing, buffers) SELECT...
> >>O explain mostra quanto de memória a consulta usa e é bem preciso.
>
> Pelo que entendi, com esse explain posso ver o uso de memória
> "shared_buffers"
> e não o "work_mem", correto?
>

Vê sim.
Exemplo, quando aparece algo como:
  Sort Method: quicksort  Memory: 25kB
Esta consulta exemplo usou 25 kB de work_mem para uma ordenaçã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

Re: [pgbr-geral] Validar valor do work_mem

2016-09-02 Por tôpico Alessandro Lima 
>>EXPLAIN (analyze, timing, buffers) SELECT...
>>O explain mostra quanto de memória a consulta usa e é bem preciso.

Pelo que entendi, com esse explain posso ver o uso de memória
"shared_buffers"
e não o "work_mem", correto?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Validar valor do work_mem

2016-09-02 Por tôpico Flavio Henrique Araque Gurgel 
Em sex, 2 de set de 2016 às 02:53, Júlio César Martini <
juliomart...@gmail.com> escreveu:

> Pessoal,
>
> Existe alguma maneira fácil de descobrir se o valor que eu defini para a
> minha work_mem é suficiente?
>
> Tenho algumas SELECTs que quando utilizo ordenação está muito lento e
> acredito que seja pelo valor da work_mem.
>

Se você sabe quais são as consultas lentas, você pode verificar o uso de
memória usando:

EXPLAIN (analyze, timing, buffers) SELECT...

O explain mostra quanto de memória a consulta usa e é bem preciso.

A outra forma é habilitando o log de temporários e analisando o log com o
PgBadger, por exemplo.

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