Re: [pgbr-geral] Nova lista PGBR

[Rafael Fialho]

Em 19 de abril de 2018 10:20, Ivo Sestren Junior 
escreveu:

> Coloque o filtro TO: pgsql-pt-ge...@lists.postgresql.org
>

É, aparentemente precisava ser o endereço completo. Parece estar ok, vou
aguardar novas threads pra garantir.
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] Nova lista PGBR

[Rafael Fialho]

Em 19 de abril de 2018 10:14, Ivo Sestren Junior 
escreveu:

> Use o campo TO: que funciona
>

Eu tenho filtros com todas as condições possíveis e não estão funcionando..
o valor do campo seria "pgsql-pt-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] Nova lista PGBR

[Rafael Fialho]

Pessoal, seria possível adicionar um prefixo no e-mail? Assim como temos
nesta lista o "[pgbr-geral]".
Seria interessante para poder adicionar marcadores/filtros às mensagens da
lista, já que pelo CC não é possível (ao menos no google).

Obrigado
[]'s

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

Re: [pgbr-geral] depuração de rotinas

[Rafael Fialho]

Em 11 de abril de 2018 15:38, Samuel Teixeira Santos 
escreveu:

> ​esse pldebugger.git não é o utilizado pelo pgAdmin?​
>

Ah sim, creio que sim, mas aparentemente nas novas versões do Advanced
Server não é necessário instalar ele por fora, que foi como sempre usei,
mas utilizava com o pgAdmin.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] depuração de rotinas

[Rafael Fialho]

Em 11 de abril de 2018 15:12, Samuel Teixeira Santos 
escreveu:

> Olá pessoal, boa tarde.
>
>
> Utilizam alguma ferramenta para depurar stored procedures/functions?
>
>
Olá, boa tarde!
Os que conheço são: https://git.postgresql.org/gitweb/?p=pldebugger.git e o
pgAdmin (tem opção de debugger).

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

Re: [pgbr-geral] Base de dados de CEP do Brasil.

[Rafael Bragatto Gratz]

Genial Wilian, valeu pela dica.

Atenciosamente
Rafael Bragatto Gratz

Projeta - Sistemas Orientados ao Seu Mundo
www.projetasistemas.com.br
Tel/Fax: (27) 3026-5959
Celular:  (27) 99244-4200

Em 4 de janeiro de 2016 11:33, Willian Jhonnes <willianjhon...@gmail.com>
escreveu:

>
> >
> > William,
> >  você sabe quem mantém o ViaCEP ? É confiável ?
> >
>
> O ViaCEP é um serviço colaborativo que usa como base o webservice dos
> correios. Tenho utilizado há uns 2 anos sem problema, inclusive para
> popular a minha base local quando a consulta é feita no webservice e eu
> ainda não possuo o CEP cadastrado.
>
> Acho mais tranquilo do que popular uma base com dados (em torno de 160MB)
> dos quais utilizarei 1 ou 2% dos dados.
>
> Willian
>
> ___
> 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] Transferir Banco Postgres para outra máquina

[Rafael Bragatto Gratz]

Considerando duas máquinas com hardware e versões de postgresql diferentes,
o processo com menor down-grade seria com o pg_dumpall​ ou há alguma outra
forma de ser feito?

No meu caso seria migração do postgresql da versão 9.0 para  a 9.6

Atenciosamente
Rafael Bragatto Gratz

Projeta - Sistemas Orientados ao Seu Mundo
www.projetasistemas.com.br
Tel/Fax: (27) 3026-5959
Celular:  (27) 99244-4200

Em 27 de junho de 2017 18:30, Douglas Ghirelli <douglasghire...@gmail.com>
escreveu:

>
>
> Em sáb, 24 de jun de 2017 às 21:19, Euler Taveira <eu...@timbira.com.br>
> escreveu:
>
>> Em 24 de junho de 2017 16:26, Luiz Henrique <luiz.henriqu...@gmail.com>
>> escreveu:
>>
>>>
>>> Desejo transferir de forma definitiva.
>>
>>
>> Uma das formas mais rápidas seria utilizando replicação. Para isso o
>> hardware/SO deve ser (quase) igual. Uma vez montada a replicação [1], basta
>> escolher uma janela de manutenção e fazer o failover (pg_ctl promote).
>>
>>
>> [1] http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html
>>
>>
>>
> Dando um feedback, recentemente fiz a migração entre regiões na AWS,
> trazendo meu serviços para South América (São Paulo), e utilizei a técnica
> q o Euler descreveu, funcionou muito bem e o downtime foi mínimo.
>
>
>
>
>
>>
>> --
>>Euler Taveira   Timbira -
>> http://www.timbira.com.br/
>>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>> <http://www.timbira.com.br>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> --
> Douglas Paulo Ghirelli
> Profissional de Tecnologia da Informaçã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

[pgbr-geral] RES: RES: RES: PostgreSQL ataque???

[Rafael Cruz]

Senhores, bom dia

 

Sou iniciante em PG, leio os e-mails mais não tenho nenhum conhecimento do 
banco, a não ser o básico mesmo, criar tabela, etc. Hoje comercialmente 
trabalho com FB

Estamos iniciando um novo projeto para a prefeitura da cidade, e uma das ideias 
iniciais é trabalhar com PG. Alguém com mais experiência pode me dar um 
direcionamento de como configurar o SGBD de forma corretae segura, ou onde 
posso encontrar material ou alguma empresa que ofereça um curso mais avançado.

 

Valeu galera... abraço a todos

 

 

 

De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de 
Flavio Rescia Dias
Enviada em: quinta-feira, 20 de abril de 2017 10:03
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] RES: RES: PostgreSQL ataque???

 

Ouvi relatos em um grupo de provedores que tem o pg aberto externamente.

 

Com relação a simplesmente trocar de porta, não acho uma boa técnica, estão 
explorando na 5432 pois devem estar escaneando assim, é uma questão de tempo 
até fazerem um nmap menos específico.

 

Alguém teve problema e o hba não estava com trust aberto?




Flávio Rescia Dias

 

Em 20 de abril de 2017 09:53, Hugo Quinteiro  escreveu:

Isso também esta acontecendo  com os clientes da minha empresa, 
pelo que percebemos aconteceu apenas onde o pg_hba.conf estava totalmente 
aberto, com trust, na segurança da senha

 

De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de 
Santiago - NSR
Enviada em: quinta-feira, 20 de abril de 2017 09:07
Para: 'Comunidade PostgreSQL Brasileira'
Assunto: [pgbr-geral] RES: PostgreSQL ataque???

 

Aconteceu o mesmo comigo hoje...com 1 clienteestou rezando para que seja só 
ele...

 

De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de 
Pedro B. Alves
Enviada em: quinta-feira, 20 de abril de 2017 08:54
Para: Comunidade PostgreSQL Brasileira
Assunto: [pgbr-geral] PostgreSQL ataque???

 

Pessoal alguém já passou por algo parecido, cheguei no escritório hoje e as 
tabelas do banco sumiram...

 

tem somente uma tabela "warning" com os seguintes dados

 

 

"Send 0.5 BTC to this address and go to this site 
http://ann2hzqgedo3plvu.onion/ to recover your database! SQL dump will be 
available after 
payment!";"1Djh8KTQFDjizvYMpdBQiNrLxiSg2gg86K";"ecnsupp...@mai2tor.com"

 

 

Alguém já viu isso??


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

[Rafael Fialho]

Em 17 de abril de 2017 10:08, Antonio Cesar 
escreveu:

> Os valores apresentado por este site são bem maiores...
>

Pois.. pra mim, para 32GB, foi sugerido 328MB para WEB/OLTP, cerca de 10%
do seu parâmetro atual.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Configuração

[Rafael Fialho]

Em 17 de abril de 2017 09:52, Antonio Cesar 
escreveu:

>
> Bom dia,
>
Bom dia!

> work_mem = 3072MB
>

Este valor está muito alto.

> alguem pode me ajudar a verificar se esta certo ou preciso mudar alguma
> coisa?
>

É difícil dizer sem um detalhamento muito grande de informações.
Aconselho, como parâmetro inicial, utilizar a ferramenta [1] do nosso
ilustre colega Sebastian, para configurações relacionadas à memória.

Quanto ao restante, teria de identificar onde está o gargalo e o que pode
estar causando o mesmo, monitorando a atividade do banco de dados e o
sistema.

[1] - https://www.pgconfig.org

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

Re: [pgbr-geral] Duvidas com encoding UTF8 x LATIN1

[Rafael Fialho]

Em 29 de março de 2017 10:52, Leandro Guimaraens Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le mer. 29 mars 2017 à 10:17, Josué Bragagnolo  a
> écrit :
>
>>
>> O melhor sempre eh migrar tudo pra UTF8, mas se não é possível atualizar
>> sua aplicação, o melhor acredito que seja manter o SO do Servidor postgres
>> em iso também
>>
>
> De maneira alguma.  O servidor pode ficar em UTF-8 (ou algum outro
> Unicode), o que o torna útil para todos os outros usos.  A rigor, até a
> base de dados deve ficar em Unicode, e apenas converter dinamicamente com o
> client_encoding, preservando a capacidade total do Unicode para quaisquer
> outros usos.  As bases costumam ganhar outros usos além da aplicação
> original, e não é sábio deixar que uma aplicação original obsoleta crie
> problemas no futuro.


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

Re: [pgbr-geral] Duvidas com encoding UTF8 x LATIN1

[Rafael Fialho]

Em 29 de março de 2017 08:55, Luiz Henrique 
escreveu:

> Pessoal,
>
> [..]
> Criei o banco em LATIN1. Na console psql aparece o erro ao testar o insert
> abaixo:
> [...]
>
> ERROR:  invalid byte sequence for encoding "UTF8": 0xc3 0x4f
>
> Tem algum parâmetro que eu preciso configurar ?
>

Possivelmente o seu client_encoding, passando para LATIN1 também.

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

Re: [pgbr-geral] Otimização da Base de Dados

[Rafael Fialho]

Em 14 de março de 2017 17:31, Rudimar  escreveu:

> eu uso o plsql assim:
> psql -c “vacuum full analyse” -d dadosadv -U postgres
> ?
>

O autovacuum não resolveria teus problemas?
Vacuum full não é recomendado, menos ainda diariamente.
Procure também no histórico da lista os motivos, mas eu recomendo utilizar
o autovacuum, e se este não estiver satisfatório, utilizar somente o vacuum
"normal", analyze e reindex em casos nos quais ele for realmente necessário.

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

Re: [pgbr-geral] PostgreSQL vs MySQL

[Rafael Fialho]

Em 24 de janeiro de 2017 16:28, Leandro Guimaraens Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Procure por MySQL gotchas, se nao me falha a memoria.
>

Obrigado, Dutra! Já é um início.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] PostgreSQL vs MySQL

[Rafael Fialho]

Boa tarde, pessoal!

Sei que já rolaram muitas discussões aqui sobre esse confronto, inclusive
quando foi divulgado pela Uber a troca de SGDB, mas gostaria de ver com
vocês se vocês tem ciência de algum material, artigo técnico, lista de
vantagens x desvantagens dos dois e etc. pra me passar, pra eu poder
compilar e repassar para a comunidade depois de apresentar este material na
empresa onde trabalho.

A ideia, como DBA PostgreSQL é mudar os paradigmas existentes de que o
MySQL supre as necessidades da empresa, porque aparentemente supre, ainda
(o volume de dados e transações diárias ainda é muito pequeno e nenhum
recurso do SGBD é utilizado, é utilizado realmente como mero repositório de
dados e relatórios, por exemplo, são gerados no back-end), porém, pela
minha experiência, sei que logo começarão a surgir os problemas e quero
fazer parte de uma solução que extinga essa possibilidade.

Agradeço a atenção e a colaboração de todos, se possível.

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

Re: [pgbr-geral] not null if

[Rafael Sousa]

Cleiton,

agradeço a atenção.

Em 19 de janeiro de 2017 11:56, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

>
>
> 2017-01-19 10:55 GMT-02:00 Rafael Sousa <rafaelps2...@gmail.com>:
>
>> é possivel colocar um not null apenas se outro campo for por exemplo true
>> ?
>>
>
> Você poderia ser mais claro no exemplo?
>
>>
>>
>>
>> ___
>> 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] not null if

[Rafael Sousa]

Obrigado Tiago, funcionou perfeitamente !



Em 19 de janeiro de 2017 12:58, Tiago José Adami <adam...@gmail.com>
escreveu:

> Em 19 de janeiro de 2017 10:55, Rafael Sousa <rafaelps2...@gmail.com>
> escreveu:
> >
> > é possivel colocar um not null apenas se outro campo for por exemplo
> true ?
>
> É possível criando um check constraint:
>
> postgres=# create database checks;
> CREATE DATABASE
>
> postgres=# \c checks;
> Você está conectado agora ao banco de dados "checks" como usuário
> "postgres".
>
> checks=# create table public.teste_check(att1a boolean not null
> default false, att2b integer);
> CREATE TABLE
>
> ## Criação da Check Constraint
> checks=# alter table public.teste_check add constraint ck_teste_2b
> check ( case when att1a is true then att2b is not null end  );
> ALTER TABLE
>
> ## Registro válido
> checks=# insert into public.teste_check(att1a, att2b) values(false,null);
> INSERT 0 1
>
> ## Registro inválido, já que attr1a é TRUE, attr2b não pode ser null
> checks=# insert into public.teste_check(att1a, att2b) values(true,null);
> ERROR:  new row for relation "teste_check" violates check constraint
> "ck_teste_2b"
> DETALHE:  Failing row contains (t, null).
>
>
>
> Adami
> ___
> 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] not null if

[Rafael Sousa]

é possivel colocar um not null apenas se outro campo for por exemplo true ?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como faz Select dentro do for loop?

[Rafael Fialho]

2017-01-06 10:20 GMT-02:00 :

> Por exemplo:
>
> FOR rResult IN SELECT lote FROM fatura WHERE ORDER BY lote
> (...)
> WHERE lote = r.lote;
>

Imagino que esteja acontecendo erro, mas sugiro que você forneça mais
informações em futuras threads, como o que está acontecendo, ambiente,
versão do postgres, etc..

WHERE lote = rResult.lote;

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

Re: [pgbr-geral] Feliz natal a todos.

[Rafael Fialho]

Em 24 de dez de 2016 21:23, "João Graciano" 
escreveu:

Todos os dias temos provas da existência de Deus: a luz do sol, as flores
no jardim... Mas foi na noite de dezembro, anos atrás, que Ele se mostrou
misericordioso conosco, colocando o Filho de seu amor entre nós. Por isso
espero que essa essência desta chama divina esteja sempre em seu coração e
que ela traga um Natal de paz e um Ano Novo de alegrias.


Igualmente pra todos! Muita paz, amor e alegrias a todos!

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

Re: [pgbr-geral] Tamanho real da base em disco

[Rafael Fialho]

Em 15 de dezembro de 2016 23:24, Euler Taveira 
escreveu:

> [...]
>
>
> [1]
> https://www.postgresql.org/message-id/CA%2BTgmobZLyLU8tFCbMqbjMWB6t%2B%
> 3DERaDo820uQEJCVAQK_Paow%40mail.gmail.com


Valeu pela explicação, Euler! Não fazia ideia, aliás, passei batido pelo
diretório de dados quando li a thread.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho real da base em disco

[Rafael Fialho]

Em 15 de dezembro de 2016 11:40, Crauss, Jacson <cra...@gmail.com> escreveu:

>
> 2016-12-15 11:37 GMT-02:00 Rafael Fialho <rafafial...@gmail.com>:
>
>> Somente analyze já serve.
>
>
>
> É, rodei o analyze em uma base menor para ser rápido, e não resolveu. Vou
> deixar rodando na base maior, vai demorar bastante, depois informo se
> funcionou (não sei se vai, ja que na menor não foi, mas...).
>

É provável que não faça diferença mesmo, é uma hipótese.. Poderia tentar
verificar o tamanho das relações também (pg_relation_size), pra identificar
se todas estão com tamanho dobrado (o que seria no mínimo estranho) ou há
alguma que apresenta este comportamento, aí seria mais fácil identificar o
problema..
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho real da base em disco

[Rafael Fialho]

Em 15 de dezembro de 2016 11:36, Crauss, Jacson <cra...@gmail.com> escreveu:

>
> 2016-12-15 11:29 GMT-02:00 Rafael Fialho <rafafial...@gmail.com>:
>
>> Primeiramente, eu refaria o teste sem realizar o vacuum full. Poderia
>> também executar um analyze na base de dados antes de executar as queries
>> para verificar o tamanho (ou neste momento também). Não tenho certeza de
>> como ele funciona, porém creio que ele não teria como obter a informação
>> sobre o tamanho das bases de origem, a não ser que tenha trazido as
>> estatísticas das bases de origem e as estatísticas não tenham sido
>> atualizadas.
>
>
>
> Eu fiz o \l+ e o select pg_database_size antes do vacuum e o tamanho já
> estava "dobrado", por isso fiz o vacuum e refiz o select ...
>

Sim, imaginei isso!


>
> "a não ser que tenha trazido as estatísticas das bases de origem e as
> estatísticas não tenham sido atualizadas." é a minha desconfiança também,
> eu mandei o exemplo de uma das bases, mas tenho 11 bases neste banco e com
> todos ocorreu o mesmo, de "dobrar" o tamanho. Vou atualizar as estatísticas
> (vacuum analyze, né?), se funcionar respondo aqui,
>

Somente analyze já serve.


>
> Obrigado, Rafael.
>

Não por isso!

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

Re: [pgbr-geral] Tamanho real da base em disco

[Rafael Fialho]

Em 15 de dezembro de 2016 11:16, Crauss, Jacson  escreveu:

>
> Estou fazendo uma troca de servidor das bases de testes. Fiz um dumpall no
> servidor antigo, e restaurei no novo servidor (zerado, sem nenhuma base, só
> com a instalação do PostgreSQL). Ao terminar o restore, fiz o VACUUM FULL
> de todas as bases
>

O vacuum full não é necessário, visto que as bases foram construídas do
zero, logo não há tuplas mortas, ou ao menos não deveria haver.


> [...]
>
Quando busco o tamanho da base no banco:
> Servidor antigo:
> select pg_database_size('pgh')/1024/1024/1024 || 'GB';
>

Obs.: Podes utilizar a função "pg_size_pretty" para realizar essa
formatação e cálculo.


>  ?column?
> --
>  410GB
> (1 registro)
>
> Servidor novo:
> postgres=# select pg_database_size('pgh')/1024/1024/1024 || 'GB';
>  ?column?
> --
>  850GB
> (1 row)
>
> Não sei como o pg_database_size funciona, como ele calcula o tamanho, mas
> aparentemente (chute, dedução) está me retornando o tamanho da base antiga
> (talvez tenha vindo esta informação já com o restore) somado ao tamanho
> real da base.
>
> Alguma idéia de como solucionar, para que mostre o tamanho real da base?
>

Primeiramente, eu refaria o teste sem realizar o vacuum full. Poderia
também executar um analyze na base de dados antes de executar as queries
para verificar o tamanho (ou neste momento também). Não tenho certeza de
como ele funciona, porém creio que ele não teria como obter a informação
sobre o tamanho das bases de origem, a não ser que tenha trazido as
estatísticas das bases de origem e as estatísticas não tenham sido
atualizadas.

Espero que ajude.

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

Re: [pgbr-geral] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Rafael Fialho]

>
> *Aonde encontrar explicações ou me passarem algumas dicas?*
>

Bom dia, Eduardo!

O que normalmente faço, convertendo bases do Windows pro Linux, é realizar
o backup passando UTF-8 como encode, e restaurando em uma base de encode
UTF-8. Funciona na maioria dos casos.
Em bases que estão como LATIN1 no Windows, é necessário passar o
encode ISO-88591 na hora de realizar o dump, também restaurando sem
problemas em uma base de encode UTF-8.

Espero que ajude.

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

Re: [pgbr-geral] Performance com select distinct

[Rafael Fialho]

2016-10-31 16:59 GMT-02:00 Marcio Meneguzzi :

> Boa tarde,
>
> Estou executando um select distinct em uma tabela com 3.5 milhoes de
> registros.
>
> Tabela e campos ficticios no select.
>
> select distinct data_itens from itens where codigo = 1 and
> data_itens between '01/01/2016' and '12/31/2016' order by data_itens
>
> O que ocorre é que a primeira vez que este select é executado, ele demora
> muito mais do que as demais vezes que ele for executado.
>
> *Primeira execução da QUERY:*
> "Unique  (cost=8.59..8.60 rows=1 width=4) (actual
> time=168565.216..168566.975 rows=233 loops=1)"
> "  ->  Sort  (cost=8.59..8.60 rows=1 width=4) (actual
> time=168565.211..168565.790 rows=14311 loops=1)"
> "Sort Key: data_movimento"
> "Sort Method: quicksort  Memory: 1055kB"
> "->  Index Scan using reproc_estoque on nota_item
>  (cost=0.56..8.58 rows=1 width=4) (actual time=157809.532..168551.829
> rows=14311 loops=1)"
> "  Index Cond: ((cod_emp = 1) AND (cod_fil = 1) AND
> (cod_reduzido_merc = 1))"
> "  Filter: ((data_movimento >= '2016-01-01'::date) AND
> (data_movimento <= '2016-12-31'::date))"
>

O campo data_movimento possui índice?
___
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 case sensitive

[Rafael Fialho]

>
> Ou tem alguma outra forma de se resolver isso ?
>>
>
> ilike.
>

Recomendo também dar uma olhada na documentação do postgres, pois
provavelmente encontrarás outras funções/operações que podem ter uma forma
pronta e bem simples de resolver.

[]'s
___
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 case sensitive

[Rafael Fialho]

>
> Ou tem alguma outra forma de se resolver isso ?
>

ilike.

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

Re: [pgbr-geral] Não consigo fazer backup

[Rafael Fialho]

Em 18 de outubro de 2016 02:49, Amir  escreveu:

> Olá... Após atualizar o Postgresql da versão 9.3 para a 9.6.0, importei
> através de roteiro de carga SQL a minha base que passou a funcionar
> normalmente no sistema para testes desta versão... mas deste então ao
> disparar o comando de cópia automática F:\so_copias\pg_dump.exe --file
> "g:\\hrb0023" --host "localhost" --port "3815" --username "postgres"
> --no-password --verbose --role "sistema" --format=c --blobs "hrb_0023"  o
> banco devolve o seguinte erro 'utf8' codec can't decode byte 0xa0 in
> position 49: invalid start byte...
>
> Então instalei o pgAdmin 4, o qual funciona normalmente, mas não retorna
> os ‘backup’ da versão 9.3 e apresenta o mesmo erro quando vou executar um
> cópia geral da base (backup).
>
> Alguém sabe qual é o meu erro..??!!!
>

Está bem confusa tua thread, mas qual a versão do pg_dump que está sendo
utilizado? (F:\so_copias\pg_dump.exe)

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

Re: [pgbr-geral] Atualização Postgresql 9.4 para 9.6 em windows 10

[Rafael Fialho]

Em 7 de outubro de 2016 09:29, José Henrique Beraldo <
henriquebera...@gmail.com> escreveu:

> Bom dia.
>

Bom dia!


> Ao instalar uma versão nova 9.6.0, apenas copiar a pasta /data para a nova
> versão, é o suficiente para que a atualização seja com sucesso?
>

Migração de versões não é tão simples assim.
Veja o item E.1.2 de [1], este explica os procedimentos que devem ser
adotados:

"E.1.2. Migration to Version 9.6
A dump/restore using pg_dumpall, or use of pg_upgrade, is required for
those wishing to migrate data from any previous release."

Lembrando que o ideal é observar todos os pontos relevantes do release
notes para verificar se podem ocorrer impactos no seu ambiente, e que o
dump gerado deve ser feito a partir dos binários da versão de destino e não
o contrário.

[1] - https://www.postgresql.org/docs/current/static/release-9-6.html

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

Re: [pgbr-geral] Query cte retornando id - Postgres 9.2

[Rafael Fialho]

2016-09-27 15:48 GMT-03:00 Patrick B :

> ...
> O que estou fazendo de errado?
>

Aparentemente o seu problema está no update, pois a subquery irá retornar
seu set de dados, porém o mesmo deveria estar na cláusula FROM. Verifique
[1] para maiores detalhes da sintaxe.

[1] - https://www.postgresql.org/docs/9.5/static/sql-update.html

Espero que ajude. Certifique-se também de que, antes do update, tudo está
funcionando de acordo.

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

Re: [pgbr-geral] Ordenar por data

[Rafael Fialho]

Deixa eu me expressar de forma diferente.. Você pode utilizar campos que
não constam na query para realizar a ordenação, e utilizar outras funções
ou campos para te auxiliar nesse serviço. O mais comum seria ter um
representante do mês (ex.: 1-12) ao invés do próprio literal com o nome do
mesmo.

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

Re: [pgbr-geral] Ordenar por data

[Rafael Fialho]

>
> Tenho um tabela com os campos Referencia e ano com os seguintes dados,
>
> Alguma sugestão ?
>

Você já tentou utilizar os campos referencia e ano pra realizar a ordenação?

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

Re: [pgbr-geral] Diversão com restrições

[Rafael Fialho]

2016-09-08 16:55 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org>:

> http://www.anserinae.net/fun-with-sql-constraints.html
>
> Ponto para quem explicar sucintamente em bom português.


Basicamente está demostrando o recurso "where" em uma unique constraint,
ou, no caso, um índice parcial.
___
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 imagem(Docker) PostgreSQL

[Rafael Nery]

Boa noite pessoas,

Alguém saberia me dar uma dica de Imagem do Postgres no dockerhub que rode
em cima do AlpineLinux?
--
Atenciosamente,
Rafael Serpa Nery
*:wq!*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Nova camiseta "PostgreSQL Rock solid database"

[Rafael Fialho]

Em 4 de julho de 2016 22:28, Fábio Telles Rodriguez 
escreveu:

> Senhores, está à venda a nova camiseta que mandei fazer para a comunidade
> em comemoração aos 20 anos do PostgreSQL.
>

Parabéns, Fábio! Ficou massa a camiseta, vou providenciar a minha!

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

Re: [pgbr-geral] invalid page in block of relation base

[Rafael Fialho]

Em 19 de junho de 2016 20:10, Alessandro Lima 
escreveu:

> Migrei uma base de dados de um postgres 9.3 debian 6 64 bits para um
> postgres 9.4.8 debian 8.4 64bits, utilizei o pg_dump do 9.3 e o pg_restore
> do 9.4
>

Para realizar a migração entre versões utilizando o pg_dump é recomendável
utilizar ambos binários da versão de destino, no caso, utilizar o pg_dump
da 9.4.8, e não da 9.3.


> ao restaurar no servidor de produção aconteceu um erro para cada índíce da
> tabela audit.logged_actions_2015_10 (log trigger particionado por mes)
> Erro: invalid page in block 9342 of relation base/16385/16585
>

Ocorre erro no dump? Normalmente, quando a tabela está corrompida na
origem, ocorre erro no dump, e não na restauração.

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

Re: [pgbr-geral] poor performance usando ILIKE - PostgreSQL 9.2

[Rafael Fialho]

>
> Você pode desacentuar e minimizar o contéudo passado como parâmetro e
>> manter o LIKE.
>>
>> `WHERE lower(functionDesacentua(col)) LIKE
>> lower(functionDesacentua(texto)) || '%'`
>>
>>
>
> O meu problema aqui é que o LIKE é case-sensitive... ou seja.. estou
> pesquisando por RYAN  SHOWER mas não sei se essas palavras estão em
> maiúscula ou minúscula... portanto.. o LIKE me retorna 0 rows.
>

Bom dia!
Pois é justamente pra isso que os dois "lower()" são utilizados, assim
estarás convertendo o texto para lower case e o campo a ser pesquisado
também, eliminando o trabalho do ilike, podendo utilizar like, pois a
pesquisa funcionará mesmo sendo case sensitive.
Pra isso, o índice também precisa ser criado com lower(col), ou qualquer
outra transformação non-volatile que o campo sofra.

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

Re: [pgbr-geral] poor performance usando ILIKE - PostgreSQL 9.2

[Rafael Bernard Rodrigues Araujo]

2016-05-13 19:13 GMT-03:00 Lucas Possamai <drum.lu...@gmail.com>:

>
>>> Em 13 de maio de 2016 10:37, Renato Ricci <renatoricc...@gmail.com>
>>> escreveu:
>>>
>>>> Até o ponto que conheço, ILIKE ignora indices.. tente fazer com LIKE..
>>>> Att.,
>>>> Renato
>>>>
>>>
>
> Se eu uso o LIKE não obtenho os mesmos resultados com a Query
>


Você pode desacentuar e minimizar o contéudo passado como parâmetro e
manter o LIKE.

`WHERE lower(functionDesacentua(col)) LIKE lower(functionDesacentua(texto))
|| '%'`

rafael
___
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 no UPSERT

[Rafael Fialho]

Em 26 de abril de 2016 11:09, Alan Tavares  escreveu:

> Estou com um problema no UPSERT estou usando o PG 9.5 e usando o recurso
> insert on conflict do ...
> tenho uma tabala de pedidos com um id serial e uso isso para fazer
> referencia do pedido no sistema.
> Acontece que quando recebo uma notificação de venda uso esse recurso do
> UPSERT para inserir se for um novo pedido
> e se ja existir fazer um update no status do pedido. O problema é que
> quando isso ocorre o id é incrementado mesmo ocorrendo o update ou não
> fazendo nada
> existe alguma maneira facil de só incrementar se houver realmente um
> insert.
>

Como campos serial possuem como default o "nextval" da sequence, esse valor
é incrementado mesmo quando rodas um "insert into" e qualquer tipo de erro
ocorre. O rollback não "decrementa" o valor da sequence, logo o
comportamento está de acordo com o padrão já existente antes do recurso "on
conflict".

Como provavelmente ocorre um erro por baixo, que é tratado pelo "on
conflict", o incremento da sequence ocorre naturalmente.

O que poderia fazer, talvez, seria uma PL para fazer esse upsert
manualmente, se você não quer que este comportamento ocorra, verificando se
irá fazer o insert ou update e deixando de utilizar o recurso. Não creio
que seja um caso de bug ou problema no recurso, talvez uma possível
melhoria.

Espero ter ajudado.

[]'s
___
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 retornando -1

[Rafael Fialho]

>
> 
>
Porém quando faço a consulta
>
> select * from "ProdutosCodigoBarras" WHERE "Codigo" = -1
>
> não retorna nada, o que poderia ser?
>

Comente a segunda parte da função, execute a função em um ambiente de
testes e, após a execução, execute o SQL da segunda parte da função para
verificar quais registros estão sendo exibidos.
Provavelmente o -1 está duplicado, gerando o erro ao inserir. Como a função
roda em transação você não vai conseguir identificar o registro.

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

Re: [pgbr-geral] Uso de shared_buffer e aumento de IOPS

[Rafael Fialho]

Em 19 de abril de 2016 11:56, Ursulino Barboza  escreveu:

> Prezados,
>
> Alguém tem alguma dica sobre diminuição do timeout com conexões ODI.
>

Favor abrir outra thread para o assunto, por gentileza.

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

Re: [pgbr-geral] converter enconding

[Rafael Bernard Rodrigues Araujo]

2016-04-15 23:33 GMT-03:00 Douglas Fabiano Specht <douglasfabi...@gmail.com>
:

>
>
> Pois é estou tentando, no php setei o header ("Content-type: text/html;
> charset=utf-8");
> na conexão com o banco  tbm setei com utf8   pg_set_client_encoding($con,
> utf8);
> mas no banco continua chegando com encoding diferente.
> sendo que meu banco esta em utf8
>


Use também a diretiva `ini_set('default_charset', 'UTF-8');`
E confira se os arquivos PHP possuem o encoding UTF-8.

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

Re: [pgbr-geral] Migrando Postgresql que versão usar ?

[Rafael Fialho]

Em 13 de abril de 2016 10:10, Luiz Henrique 
escreveu:

> Você terá que, obrigatoriamente, se preocupar com charset/encoding. Qual
> versão do delphi você utiliza, e qual o encoding de sua base atualmente?
>
> Delphi 2007 e encoding LATIN1
>

Pois então, o padrão de encoding das bases é unicode, logo você terá que
avaliar isso, se pretende ir por esse caminho, ou se irá continuar no
Latin1. Isso reflete diretamente em sua aplicação.
Creio que o Delphi 2007 ainda não seja unicode, então o segundo caminho
parece o mais indicado, mas vale dar uma boa atenção pra isso.

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

Re: [pgbr-geral] Migrando Postgresql que versão usar ?

[Rafael Fialho]

Em 13 de abril de 2016 09:22, Luiz Henrique 
escreveu:

> Pessoal,
>
> Trabalho com aplicação Delphi cliente servidor usando postgres 8.2.17
>

Você terá que, obrigatoriamente, se preocupar com charset/encoding. Qual
versão do delphi você utiliza, e qual o encoding de sua base atualmente?


> Vou iniciar estudos de migração para versão 9
> A dúvida : para qual versão os colegas sugerem migrar ? posso ir direto
> para mais nova ? 9.5 ?
>

Concordo com o Dutra, 9.5, sem dúvidas.


> Ou algo mais conservador ? tipo 9.1 ou 9.3 ?
>

Não há necessidade. Se for por questão de bugs, deve ser intrínseco de que
qualquer versão pode apresentar problemas, e todas receberão correções.
Migração também é algo complicado, então você deve usar a versão que menos
trará essa necessidade em um certo período de tempo.


> Alguem sugere tutorial ?
> A aplicação não usa nada de específico no banco, operações básicas mesmo.
> Sem triger, functions,etc. Obrigado pela dica!
>

Não conheço um tutorial, mas poderia te apresentar alguns tópicos:
- encoding;
- bytea_output;
- casts implícitos (deixam de existir a partir da versão 8.3, se não me
engano, então deve se preocupar com comparações "varchar=integer", por
exemplo, que deixarão de funcionar);
- standard_conforming_strings (o default muda de off para on, e para o
Deplhi, pela minha experiência, é necessário que esteja desligado);

Em caso de dúvidas mais específicas, enquanto estiver montando o teu
ambiente de testes, traga pra gente também, há muita gente que pode te
ajudar.

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

Re: [pgbr-geral] Ferramenta de DIFF para PostgreSQL

[Rafael Fialho]

2016-04-12 18:16 GMT-03:00 Alexsander Rosa :

> Depois de experimentar as 2 antigas (pgdiff e apgdiff) acabamos criando
> uma.
>

Bom dia!
Não tive oportunidade de testar ainda, mas, desde já, parabéns pela
iniciativa!

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

Re: [pgbr-geral] Reinício do ID de Transações

[Rafael Fialho]

Em 7 de abril de 2016 01:49, Marcio Junior Vieira <
mar...@ambientelivre.com.br> escreveu:

> Fiz por dump e restore !
>
> Valeu pessoal
>

[off-topic]
*Sebastian se revira em sua cadeira.*

Marcio, por favor, atente a evitar o top-posting (responder no topo da
mensagem), conforme já foi pedido por outros colegas.
É simples, basta editar sua resposta antes de sair escrevendo.
Responda comentando cada tópico da mensagem ou simplesmente responda no
final dela, como estou fazendo, caso contrário, quem utiliza outros meios
para verificar o histórico da lista não entenderá nada.

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

Re: [pgbr-geral] CONVERSÃO DE BANCO SQL_ASCII

[Rafael Fialho]

Em 6 de abril de 2016 12:54, Wagner Vieira Furno - Lobotech <
wag...@lobotech.com.br> escreveu:

> Boa tarde!
>

Boa tarde!


> Temos um banco de dados ainda com encoding SQL_ASCII e bem populado.
>
> Existe ferramenta de conversão automática para UTF-8 que evite perda de
> dados ?


Não sei sobre ferramenta de conversão automática..
O que sempre fiz pra migração de bases SQL_ASCII para UTF-8 foi a conversão
manual com dump + restore, realizando dump pelo pg_dump da versão de
destino e adicionando o parâmetro --encoding=ISO88591.
Pra mim, sempre funcionou perfeitamente. Espero que ajude.

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

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Rafael Fialho]

Em 6 de abril de 2016 09:01, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> 
> Se tiverem interesse de replicar o problema
>
> Tenham uma tabela grande (uns 30GB com blobs)
> façam um
> begin;
> muitos deletes (50% da base)
> commit;
> Vacuum full analyse verbose 
>
> Mesmo quando fiz:
> checkpoint
> Vacuum full analyse verbose 
>
> não fez diferença
>

Você já verificou a situação da atualização dos binários, como já relataram
anteriormente? Pelo que li nas mensagens, essa situação parece ter sido
ignorada.
Se não houve atualização da release, creio que seria um bom ambiente pra
você mesmo tentar fazer a reprodução do problema em uma versão atualizada.

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

Re: [pgbr-geral] RES: Problemas de desempenho

[Rafael Fialho]

2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> > Bom dia,
> >
> >
> > Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> > e após atualização esta query passou a ficar extremamente lenta.
> >.
> >
> >
> > Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> > to achando o furo.
> > Observem que na versão 9.0 estava funcionando de forma satisfatoria.
> >
>
>
> Atualize as estatísticas com o comando ANALYZE.
> http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html
>
>
> Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as
> estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze
> e to me batendo nisso a horas).
> Mas eu havia feito todas as manutenções antes de enviar a saída do analyze
> e inclusive peguei o banco e subi numa máquina minha e continua na mesma
> lentidão.
>
> Talvez precise que eu envie mais alguma informação pra ajudar?


O tempo estimado e o tempo real são muito divergentes, talvez por isso a
sugestão do analyze, e também porque é praxe que as estatísticas estejam
desatualizadas.
Utilize [1] para facilitar a visualização, se possível, e cole a URL do seu
explain.
O problema parece começar em alguns loops e filtros sem índices, mas será
melhor de visualizar após nos passar o link do explain.
Eu tentei utilizando o resultado que você passou e não deu certo.

[1] - http://explain.depesz.com/

[]'s
___
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_catalog - conteúdo de função

[Rafael Fialho]

Em 30 de março de 2016 15:11, André Ormenese  escreveu:

> Minhas funções estão todas em plpgsql e nada aparece nesta coluna. Estão
> em fontes externas ? Existe uma forma de acessá-las ?
>

Se são funções que você desenvolveu, em plpgsql, você deveria ter acesso.
As fontes externas são em caso de funções compiladas, feitas em C.
Você está logado como superuser? Se não me engano, usuários comuns não
podem ver os fontes, mas posso estar enganado.
Verifique também a documentação[1] para ver se algo pode te ajudar.

[1] - http://www.postgresql.org/docs/current/static/catalog-pg-proc.html

[]'s
___
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_catalog - conteúdo de função

[Rafael Fialho]

Em 30 de março de 2016 15:03, André Ormenese  escreveu:

> Boa tarde pessoal.
>
> Estou precisando acessar o conteúdo das funções de um determinado schema,
> e fazer uma busca dentro do código.
>
> Vi que na pg_proc consigo um monte de informações das funções, mas o
> código da função não achei.
>
> Onde fica armazenada essa informação ??
>

Boa tarde!
Nesta tabela mesmo, campo prosrc. Note que em alguns casos, dependendo do
tipo da linguagem e do código dos métodos, estes podem estar escritos em
fontes externas, como é o caso dos métodos do catálogo.

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

Re: [pgbr-geral] {:Code Redux} | Upsert; A Few Bad Apples

[Rafael Fialho]

Em 26 de março de 2016 08:18, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> http://coderedux.com/on-postgresql/upsert-bad-apples
> Artigo bem interessante sobre chaves.


Obrigado por compartilhar!

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

Re: [pgbr-geral] Adicionar coluna com default de outro campo

[Rafael Fialho]

Em 29 de março de 2016 15:37, Victor Fugiwara 
escreveu:

> Boa tarde pessoal,
>

Boa tarde!

Preciso adicionar um campo em uma tabela, sendo que o valor deste campo se
> baseia na existência de um outro. A ideia seria algo assim:
>

> ALTER TABLE tabela ADD COLUMN coluna boolean DEFAULT (outracoluna IS
> NULL);
>

>
Ou seja, adiciono o campo e seu valor padrão depende do que tem preenchido
> em outra coluna da tabela. A necessidade disso é pra evitar o alter table
> seguido de um update. O valor default seria removido em seguida, essa regra
> seria apenas para a criação desse campo.
>

Ocorre que, por baixo, não há como escapar do "update". Você pretende fazer
isso para ter um alter table mais "performático"? Ele não será, com o
default, muito mais rápido do que um update com as devidas otimizações
(desabilitar triggers e etc.), na teoria.


> O comando desse formato dá o erro: ERRO:  não pode utilizar referência à
> coluna na expressão padrão
>
> Existe alguma forma de fazer isso sem a necessidade do update?
>

Talvez haja outra possibilidade, mas como uma coisa é inerente à outra,
talvez não seja viável. Qual seria o problema que estás enfrentando para
evitar o update?

[]'s
___
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

[Rafael Fialho]

Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:

> Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o primeiro
> paragrafo da documentação:
>
> "...pg_dump is a utility for backing up a PostgreSQL database. It makes
> consistent backups even if the database is being used concurrently. *pg_dump 
> does
> not block other users accessing the database (readers or writers)*..."
>
>
Boa tarde.
Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
conforme a própria documentação informa, utiliza SELECTS, e estes, para que
o ACID seja mantido, podem promover diversos tipos de bloqueios nas tabelas
que estão sendo processadas.
Na prática, existe a possibilidade de uma tabela ficar indisponível
enquanto está sofrendo o dump, e por isso o colega não está errado ao
informar que usuários ficam com operações bloqueadas.

Não existe uma forma de evitar isso com o pg_dump, ou ao menos não conheço.
O que existem são outras soluções de backup que podem amenizar estes
problemas, como replicação, por exemplo. Aí vai da sua real necessidade e
possibilidades.

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

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Rafael Fialho]

Em 5 de março de 2016 16:10, Ali do Amaral Pedrozo 
escreveu:

> Olá!
>
>
> Sou iniciante no Postgres! Tenho uma aplicação em SQL SERVER 2014 EXPRESS
> desenvolvida em Delphi XE 8 e estou migrando para o Postgres 9.4.
>
> No ambiente de testes funciona tudo perfeitamente, porém, quando eu me
> conecto em um Postgres remoto (instalado em um Debian 8 ), a conexão, e a
> recuperação de dados é lenta.
>
> Informações gerais do ambiente remoto:
> - Servidor: Debian 8
> - Banco: Postgres 9.4 + postgis
> - Banda: 4MB ADSL
> - pg_hba.conf (acrescentei apenas essa linha para acesso remoto)
>
> hostall all 177.42.58.148/32md5
>
> - postgres.conf (alterei somente esta linha para acessar remoto)
> listen_addresses = '*'
>
>
> Informações gerais do ambiente onde está minha aplicação em Delphi:
> - Windows 8.1
> - Banda 15 MB ADSL
>
> Alguns testes que eu já fiz:
> 1) no pgadmin, se eu faço select * from compra (tenho 18 campos) com a
> tabela zerada, ele apresenta 301 ms, porém, demora 21s para exibir a
> informação
> 2) via psql no windows,
> psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s)
> \connect database (demora 2s)
> select * from compra; (instantaneo)
> 3) via delphi, conectando via firedac (demora 5s)
> 4) via delphi, quando eu faço tfdquery.open (demora 5s)
>

As informações parecem meio desencontradas..
O pgadmin demora 21s para não exibir nada (ou existe dados?) e o firedac
demora 5s? Por que a demora seria no firedac, visto que o pgadmin demora
mais? E por que a diferença em relação ao psql? São ambientes
diferentes/testes diferentes?

Não consegui entender muito bem. O colega já conseguiu algum realizar algum
progresso?

Como já foi alertado por alguns, de certa forma, o firedac foi projetado
para aplicações client-server, e provavelmente não funcione tão bem para
bancos remotos, conectando de maneira direta e reta (como num ambiente
client-server), porém, cabe checar diversos outros tipos de problemas que
podem estar ocorrendo.

Se o colega pudesse dar algum retorno sobre seu progresso e seu ambiente,
para que a discussão possa auxiliá-lo, seria muito bacana.

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

Re: [pgbr-geral] Minimal Database dump file

[Rafael Bernard Araujo]

Oi, Lucas.

On Wed, Mar 2, 2016 at 10:00 PM, drum.lu...@gmail.com <drum.lu...@gmail.com>
wrote:

>
> Mas deste modo eu não teria as foreign keys certo?
>


A opção `--schema-only` vai trazer as chaves estrangeiras sim. O seu script
de 1.000 linhas é que pode falhar em algumas linhas por não existirem as
correspondentes nas 1.000 linhas de uma tabela primária. Mas isso não seria
problema, já que seu objetivo é pegar uma pequena parte do banco para
testes.

Acho que a sua idéia já está pronta para funcionar.

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

Re: [pgbr-geral] Primeira Função

[Rafael Nery]

> Ola pessoal,
>>
> ​Olá!​


> sempre trabalhei com o firebird, porem venho migrando para o postgresql,
>> porem tenho me esbarrado em algumas coisas que podem ser basicas para voce,
>> mais pra eu vem dando um baita trabalhão.
>>
>> Estou tentando criar a seguinte função basica, só para eu entender o
>> funcionamento da mesma, e aplicar mais informações a ela.
>>
>> A Function em sim é criada sem erro:
>>
>>
>> Create or Replace Function fluxo_base(date, date) returns setof cliente as
>> '
>> declare
>> data date;
>>   begin
>> return query SELECT
>>   financeiro.id,financeiro.data_vencimento,
>>   financeiro.numero_documento,
>>   (SELECT sum(valor_parcela) FROM financeiro WHERE tipo_conta = "R"  and
>> data_vencimento between $1 and $2) AS "Valor a Receber",
>>   (SELECT sum(valor_parcela) FROM financeiro WHERE tipo_conta = "P" and
>> data_vencimento between $1 and $2) AS "Valor a Pagar"
>> FROM
>>   financeiro;
>> return;
>>   end
>> '
>> language 'plpgsql'
>>
>>
>> Porem quando eu chamo ela assim:
>>
>> ​​
>> select * from fluxo_base("05/03/2015","20/07/2018");
>>
>> ​​
select * from fluxo_base('05/03/2015','20/07/2018');​

Ela gera o seguinte erro:
>>
>> ERROR:  column "05/03/2015" does not exist
>> LINE 1: select * from fluxo_base("05/03/2015","20/07/2018");
>>  ^
>> ** Error **
>>
>> ERROR: column "05/03/2015" does not exist
>> SQL state: 42703
>> Character: 26
>>
>>
>> ​

A grosso modo, utilize "(aspas duplas) para tabelas, campos... E utilize
'(apóstrofo) para delimitar strings/valores.

Maiores informações
http://www.postgresql.org/docs/9.5/interactive/sql-syntax-lexical.html

--
Atenciosamente,
Rafael Serpa Nery
*:wq!*
​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Vídeo Hacking PostgreSQL - Parte 1

[Rafael Fialho]

Em 24 de fevereiro de 2016 20:56, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> Pessoal,
>
> De acordo com $SUBJECT gostaríamos de divulgar, eu e o amigo Dickson
> Guedes, o primeiro vídeo [1] de uma série, em que iremos demonstrar como
> desenvolver uma funcionalidade para o core do PostgreSQL.
>
> Neste vídeo demonstramos o problema [2] e um exemplo da funcionalidade
> implementada em PL/SQL [3].
>
> Nos próximos vídeos demonstraremos a preparação de um ambiente de
> desenvolvimento em C com Linux, testes de regressão, alguns 'internals'
> do PostgreSQL e a própria implementação da solução no core. Como uma
> questão de organização, os vídeos estarão reunidos em um canal do
> Youtube especialmente chamado de Hacking PostgreSQL [4].
>
> A nossa ideia é publicar um vídeo por semana, de forma simples e
> prática, com a evolução do código, até o ponto de termos um patch para
> submetermos para a pgsql-hackers.
>
> Além de compartilhar conhecimento e desmistificar um pouco o
> desenvolvimento do PostgreSQL, a intenção do vídeo também é participar,
> se ainda tivermos tempo hábil, do “Concurso Melhor Artigo sobre
> PostgreSQL” [5] lançado pelo Fábio Telles antes de sua viagem para
> PGConf Russia 2016 [6].
>
> Fiquem a vontade para críticas e/ou sugestões.
>

Por enquanto só agradecimento e parabenizações. Parabéns pela iniciativa!

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

Re: [pgbr-geral] Melhorias da versão 8.1 para versão 9.5

[Rafael Fialho]

Em 18 de fevereiro de 2016 09:24, Marco Aurelio 
escreveu:

> Caros,
>
> É o seguinte, tenho alguns servidores legados (bem legados mesmo, rsrsrs)
> que estão ainda com a versão 8.1 do postgresql, e estou precisando
> convencer a direção a migrar para a versão corrente 9.5, sei que tem os
> "whats new" de cada release, e sei que o principal motivo é que o
> postgresql não dá suporte mais pra esta versão, mas gostaria de compilar as
> principais novidades e melhorias em relação a versão 8 para juntar num doc
> para convencer o pessoal.
> Então, aceito sugestões, rsrsrs.
>

É um salto bem grande.
Lembro que a última migração que fiz foi da versão 8.2, e demorou bastante
pra ser realizada principalmente por conta da falta dos casts implícitos.
Mas existe uma infinidade de melhorias e novidades, principalmente no que
diz respeito à segurança (principalmente o que já foi levantado sobre o
suporte), desempenho e recursos.
O desempenho é incomparável. Há uma melhora MUITO grande, mesmo em rotinas
que podem vir a não sofrer alterações.
A quantidade de recursos novos é indiscutível, tanto para desenvolvedores
quanto para DBAs. Há window functions, annonymous blocks, o "with" para
queries mais complexas, refatoração do autovacuum (que era bastante
complicado de utilizar em versões antigas), "upsert", materialized views,
etc, etc..

Boa sorte. FDI é complicado, mas o mais importante de tudo é demonstrares
confiança com um bom embasamento e estudo sobre a proposta.

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

Re: [pgbr-geral] ERROR: canceling statement

[Rafael Bernard Rodrigues Araujo]

oi, lucas.

2016-02-10 20:27 GMT-02:00 drum.lu...@gmail.com <drum.lu...@gmail.com>:

> O erro a baixo pode ser devido a Query estar "errada"? Ou seria um
> problema relacionado a recursos da máquina/DB?
>
> ERROR:  canceling statement due to statement timeout
>

pode ser uma consulta que esteja levando muito tempo ou pode ser o recurso
da máquina que não consegue dar o resultado no tempo configurado.

a configuração statement_timeout do postgresql.conf é o que define o tempo
máximo que a consulta ocupará na conexão sem um resultado. é preciso
verificar se isso não é gerado por uma consulta em particular ou se é em
algum período de alto acesso que acaba deixando o servidor mais ocupado e
demorando mais a responder às consultas.

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

[pgbr-geral] always-do-this-4-put-stats_temp_directory-on-a-memory-file-system

[Rafael Bernard Rodrigues Araujo]

Olá, pessoal.

Recentemente o Lucas Possamai comentou comigo que resolveu um problema de
alto uso de I/O com a alteração de stats_temp_directory. E hoje eu me
deparo com alguém novamente mencionando esta questão. Então, acho que é
importante:

http://thebuild.com/blog/2016/02/02/always-do-this-4-put-stats_temp_directory-on-a-memory-file-system/

Abraços,
--
Rafael Bernard Rodrigues Araújo
about.me/rafaelbernard
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] COMPORTAMENTO DE FUNÇÃO EM INDICES

[Rafael Bernard Rodrigues Araujo]

Olá, Eduardo.

2016-01-27 20:37 GMT-02:00 Eduardo Az - EMBRASIS <eduard...@embrasis.com.br>
:

>
>
> CREATE INDEX cadastro_nome_idx
>   ON public.cadastro
>   USING btree
>   ( unaccent(nome) COLLATE pg_catalog."default");
>
> MENSAGEM DE ERRO:
> ERROR:  functions in index expression must be marked IMMUTABLE
>

unnacent é volátil (por causa da necessidade do locale/dicionário). Para
índices, você terá que manter a sua própria função (que é IMMUTABLE).

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

Re: [pgbr-geral] Abordagem correto de select para ter o retorno esperado

[Rafael Bernard Rodrigues Araujo]

2016-01-27 16:34 GMT-02:00 Rubens José Rodrigues <
rubens.rodrig...@batistarepresentacoes.com>:

> Eu tentei usar Window Function sem sucesso, na verdade nem sei se é
> adequado
> para isso. Eu consegui usando um função, porém acho que pode haver uma
> forma
> direta.
>

Window Functions atende ao seu caso muito bem. Você também pode escolher
usar subquery. A Window Function organiza melhor, todavia.

Na Windows function você pode pegar os itens com max(VALOR) agrupado pelo
CODCTI. Com isso você tem como consultar na tabela final cruzando com o
resultado da Window Funcition.

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

Re: [pgbr-geral] ERROR: deadlock detected - PostgreSQL 9.2

[Rafael Bernard Rodrigues Araujo]

2016-01-25 7:09 GMT-02:00 drum.lu...@gmail.com <drum.lu...@gmail.com>:

> Ao rodar a DDL (ver anexo) com BEGIN e ROLLBACK eu recebo um erro.
> Alguém por favor poderia me explicar o por que isto acontece? Uma vez que
> a coluna da linha 23 não existe na DB.
>


Lucas, de qualquer maneira, é interessante verificar os locks existentes e
tratá-los.

===

select  locktype, database,
relation,page,tuple,virtualxid,transactionid,classid,objid,objsubid,virtualtransaction,pid
,   
mode,granted,datname,datdba,datctype,datistemplate,datallowconn,datconnlimit,datlastsysoid,datfrozenxid,dattablespace,datacl
,   c.relname as table_name
frompg_locks l
join pg_database d
on d.oid = l.database
join pg_class c
on c.oid = l.relation;


===

Observe se o lock existe antes de executar o bloco de código ou se ele é
causado pela execução do próprio bloco de código.

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

Re: [pgbr-geral] Query - Construção - PostgreSQL 9.2

[Rafael Fialho]

Em 22 de janeiro de 2016 06:35, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Já resolvi o problema... O Rafael aqui da Lista deu uma ajuda também!
>>
>> Lucas.
>>
>
> Acabei achando o assunto original, vi que o Rafael sugeriu que fizesse um
> analyze no seu banco de dados. Foi isso que te resolveu o problema?
>

Na verdade ele precisava de rotinas que o ajudassem a diminuir a latência
do seu servidor, e fez isso otimizando o modelo de dados.
Pra isso foi feita uma nova tabela, via copy, e uma função pra auxiliar no
preenchimento de um número de "rótulo" pros registros.

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

Re: [pgbr-geral] Query - Construção - PostgreSQL 9.2

[Rafael Fialho]

Em 22 de janeiro de 2016 10:14, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Em 22 de janeiro de 2016 06:35, Flavio Henrique Araque Gurgel
>> <fha...@gmail.com <mailto:fha...@gmail.com>> escreveu:
>>
>>     Já resolvi o problema... O Rafael aqui da Lista deu uma ajuda
>> também!
>>
>> Lucas.
>>
>>
>> Acabei achando o assunto original, vi que o Rafael sugeriu que
>> fizesse um analyze no seu banco de dados. Foi isso que te resolveu o
>> problema?
>>
>>
>> Na verdade ele precisava de rotinas que o ajudassem a diminuir a
>> latência do seu servidor, e fez isso otimizando o modelo de dados.
>> Pra isso foi feita uma nova tabela, via copy, e uma função pra auxiliar
>> no preenchimento de um número de "rótulo" pros registros.
>>
>
> É uma pena que essa discussão rica não tenha passado aqui pela lista.
> Ou pode ser que eu tenha perdido algo...


Acredito que sim, o colega mandou dois e-mails, o outro que tinha mais
detalhes, mas a solução não encontra-se, de certa forma, nele, só o caminho
pra ela. Acho que as dúvidas também não ficaram muito claras.. Fui atrás
por private porque realmente não tinha entendido quase nada.

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

Re: [pgbr-geral] Query - Construção - PostgreSQL 9.2

[Rafael Fialho]

Em 22 de janeiro de 2016 11:27, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> É uma pena que essa discussão rica não tenha passado aqui pela lista.
>> Ou pode ser que eu tenha perdido algo...
>>
>>
>> Acredito que sim, o colega mandou dois e-mails, o outro que tinha mais
>> detalhes, mas a solução não encontra-se, de certa forma, nele, só o
>> caminho pra ela. Acho que as dúvidas também não ficaram muito claras..
>> Fui atrás por private porque realmente não tinha entendido quase nada.
>>
>
> Como eu havia dito, é uma pena, muita informação rica ficou apenas entre
> vocês dois. Se os esclarecimentos tivessem corrigo em público, mais pessoas
> poderiam ajudar e a ajuda toda beneficia a todos.
>
> Mas enfim, é vosso direito fazer assim.


Claro, concordo plenamente! Porém, o assunto estava bem confuso e o colega
precisava de ajuda urgente.
Fique tranquilo, Flávio, ele ainda está trabalhando na solução, acredito eu.
Tenho certeza que, ao chegar nela, ele dividirá suas experiências por aqui.
;)

[]'s
___
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 RETURNING em Update

[Rafael Bernard Rodrigues Araujo]

Bom dia, Cleiton.

2016-01-20 9:35 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

>
> Alguém tem alguma experiencia, problemas, etc...?
>


Eu uso RETURNING e funciona como esperado. Nehuma anomalia.


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

Re: [pgbr-geral] Schema ou Database distintas?

[Rafael Bernard Rodrigues Araujo]

Olá, Felipe.

2016-01-18 10:01 GMT-02:00 Felipe Moura <felipegu...@gmail.com>:

>
> Pessoal, estamos passando por um situação onde a equipe de banco de dados
> afirma que trabalhar com esquema no postgres é inseguro e a solução dada
> seria utilizar uma database para cada sistema.
>


Qual é a insegurança apresentada?
Sem informações adicionais, eu diria que a segurança (ou falta de) é a
mesma usando esquemas ou bancos separados. A segurança de acesso no banco é
a partir da autorização de acesso de cada usuário.


>
> Alguém já passou por algo parecido?
>


Sim. Minha separação entre bancos e esquemas é decidido pela estrutura da
aplicação, pois em relação a segurança, temos a mesma.

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

Re: [pgbr-geral] Oferta de trabalho PostgreSQL na Alemanha - Com visto para trabalho

[Rafael Fialho]

2016-01-18 14:42 GMT-02:00 Tiago José Adami :

> Olá pessoal.
>
> Recentemente fui contactado via LinkedIN por um recrutador chamado
> Sebastian White. Ele está procurando um profissional em PostgreSQL que
> tenha bons conhecimentos em otimização, upgrades, incidentes e shell script
> (Python é um "plus a mais") para trabalhar em Berlin, sendo necessário
> inglês avançado/fluente.
>
> Eu não conheço o Sebastian, apenas troquei alguns e-mails com ele. Não
> parece ser uma falsa proposta, inclusive as entrevistas iniciais serão
> feitas por Skype. Confesso que fiquei muito interessado na proposta, mas
> por motivos pessoais não posso sair do Brasil e não segui adiante.
>
> Logo, quem possuir interesse entre em contato com Sebastian pelo LinkedIN:
> https://www.linkedin.com/in/sebastian-white-13272b26
>
> ...ou envie um e-mail solicitando mais informações sobre a vaga ao
> endereço: sebastian -at- stelfox -dot- ie
>

Obrigado por compartilhar, Tiago!

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

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Rafael Bernard Rodrigues Araujo]

Recomendo também ter um repositório com controle de versão das
funções/procedimentos.

2016-01-18 13:58 GMT-02:00 Douglas Fabiano Specht <douglasfabi...@gmail.com>
:

>
> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
> negocio? Pgsql, Java, Perl, Phyton, C?
>


PL/PGSQL para PostgreSQL e PL/SQL para Oracle.



> 4-Pensando em multi banco, qual das linguagens eu poderia aproveitar no
> postgresql e tambem no Oracle
>


São duas linguages diferentes, então será necessário ter a versão da função
em cada linguagem mesmo.

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Fialho]

Em 15 de janeiro de 2016 22:21, iannsp  escreveu:

>
>
> On 1/15/16 3:14 PM, Flávio Alves Granato wrote:
> > On 15-01-2016 14:19, iannsp wrote:
> >> Eu não consigo enxergar beneficios em ser "multi database" a não ser
> >> aumentar as possiblidades de venda, salvo casos em que esse é o papel do
> >> software (orquestrar varias sgdb engines)
> >...


Pessoal, vamos tentar evitar os flames..
O melhor jeito de se ter uma discussão saudável é respeitando a opinião
alheia, e isso serve pra todos.
Entendo que todo mundo quer expor seu ponto de vista e quer ser respeitado,
então que comece fazendo isso com o próximo.
Aqui somos todos iguais, independente se desenvolvedor, DBA, SysAdmin ou o
que for, todos estão aqui pra contribuir, participar e aprender, e é esse o
objetivo.

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Fialho]

Em 16 de janeiro de 2016 11:45, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le 16 janvier 2016 11:16:28 GMT-02:00, Rafael Fialho <
> rafafial...@gmail.com> a écrit :
> >Em 15 de janeiro de 2016 22:21, iannsp <ian...@gmail.com> escreveu:
> >>
> >> On 1/15/16 3:14 PM, Flávio Alves Granato wrote:
> >> > On 15-01-2016 14:19, iannsp wrote:
> >> >> Eu não consigo enxergar beneficios em ser "multi database" a não
> >ser
> >> >> aumentar as possiblidades de venda, salvo casos em que esse é o
> >papel do
> >> >> software (orquestrar varias sgdb engines)
> >
> >Pessoal, vamos tentar evitar os flames..
>
> O colega não falou nada demais, não procuremos pêlo em ovo.
>

Concordo, Dutra, mas as respostas estão ficando diretas demais, e sabemos
muito bem onde isso termina.
As mensagens dele não são as únicas nesse sentido, não foi uma resposta
direta ao mesmo, e sim um pedido a todos.

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Bernard Rodrigues Araujo]

2016-01-15 9:04 GMT-02:00 Lucas Viecelli <lviecelli...@gmail.com>:

>
> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é
>> quase unanimidade entre desenvolvedores a contrariedade em deixar as regras
>> de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito.
>>
>
> Acredito que devemos ter bom senso, nem tudo deve ser implementado no
> Banco, e nem tudo na aplicação, sempre vale a pena entender os prós e
> contras.
>


Por isso também é imprescindível a fase de análise e arquitetura da
aplicação. Infelizmente, muitas vezes esta parte do processo é ignorada ou
então envolta em burocracia. Seria neste momento que, analisando a
proposta, complexidade e característica de cada projeto, se decida aonde as
regras de negócio estarão e o porquê. Eu diria que também nesta fase se
ganha muito discutindo com seriedade toda a tecnologia envolvida, se ela se
adequa a necessidade do projeto em cada ponto.

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Fialho]

Em 15 de janeiro de 2016 12:05, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le 14 janvier 2016 18:25:05 GMT-02:00, Saraiva Silva <
> matheus.sara...@gmail.com> a écrit :
> >Isso é um assunto recorrente no meio da comunidade de desenvolvimento,
> >e é
> >quase unanimidade entre desenvolvedores a contrariedade em deixar as
> >regras
> >de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito.
>
> Infelizmente, unanimidade entre desenvolvedores não quer dizer
> praticamente nada, a não ser popularidade, dadas as deficiências culturais
> e de formação na Informática.
>
> Temos de olhar os fundamentos.  O único livro que já vi abordar isso do
> ponto de vista conceitual foi _What, not how_, do Chris(topher) J Date.
>
> Resumindo: todos os argumentos para manter as regras de negócio são
> circunstanciais, decorrentes ou da cultura de determinadas pessoas ou
> organizações (tipicamente a síndrome do não-foi-inventado-aqui) ou do
> estado de determinado ferramental: deficiências em SGBDs ou preferências
> por determinado ambiente de programação.
>
> Por outro lado, só no SGBD as regras podem ser implementadas (1)
> obrigatória e coerentemente, independente de eventuais defeitos ou mudanças
> em programas aplicativos; (2) eficientemente, com mínima latência e com o
> planejador escolhendo o melhor caminho de execução de acordo com o estado
> do sistema e dos dados; (3) sem duplicação de esforços; (3)
> declarativamente, de acordo com o modelo de dados.
>
> Isso dito, ainda há as tais circunstâncias, que podem forçar uma escolha
> não-ideal por manter as regras fora da base de dados.  Mas muitas dessas
> circunstâncias não passam do uso de um SGBD ruim, que não tenha a riqueza
> de linguagens e ferramentas de desenvolvimento do PostgreSQL, ou ignorância
> desses recursos que o PostgreSQL oferece.
>
> Neste sentido, faz falta concorrência.  Nenhum SGBD tem o ferramental de
> linguagens de programação e riqueza lógica do SQL que o PostgreSQL tem, e
> isso até mesmo faz com que muitos decidam não usar esses recursos em nome
> de certa portabilidade, que eu creio ilusória.  E muitos sistemas tornam-se
> muito piores do que poderiam por isso, usando apenas uma espécie de mínimo
> denominador comum, que nem sequer é realmente comum, do SQL e PLs.


+1.

+1 também para o artigo do Telles.

As avaliações realizadas no mercado de trabalho normalmente são mais
circunstanciais do que fundamentais,  o que propaga o mal entendimento e
transforma péssimos fundamentos em regra, por serem utilizados pela
maioria, que sequer avalia a qualidade do que tem, e se baseia mais nos
"fundamentos" utilizados em suas aplicações e serviços para determinar sua
qualidade do que na própria qualidade dos mesmos.

[]'s, e parabéns a todos pela discussão, temos visto muitos tópicos
interessantes e produtivos!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Bernard Rodrigues Araujo]

2016-01-15 13:50 GMT-02:00 Rafael Fialho <rafafial...@gmail.com>:

>
> Aproveitando o gancho, creio que a pergunta seria produtiva pra todos.
> Como vocês costumam rebater um FDI sobre manter a regra no banco quando
> vêm argumentos como: "E se trocarmos de banco?", "E se cliente X quiser que
> o banco seja tal?"
>


Se trocar a linguagem de programação (mais comum que trocar de banco),
também é preciso reescrever.

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Fialho]

Em 15 de janeiro de 2016 13:38, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le 15 janvier 2016 13:02:22 GMT-02:00, iannsp  a écrit :
> >Eu tento definir esse problema com a seguinte frase "quanto maior a
> >distancia entre o dado e a regra de negócio maior a possibilidade de
> >interferencia e consequente falha".
>
> Gostei do sumário.


Aproveitando o gancho, creio que a pergunta seria produtiva pra todos.
Como vocês costumam rebater um FDI sobre manter a regra no banco quando vêm
argumentos como: "E se trocarmos de banco?", "E se cliente X quiser que o
banco seja tal?"

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

Re: [pgbr-geral] Query - Construction

[Rafael Fialho]

2016-01-14 9:54 GMT-02:00 drum.lu...@gmail.com :

> Olá, Ok.. Index criado e mais dados do DDL:
>

Lucas, tente responder abaixo de cada tópico da resposta, e não no topo da
mensagem (top-posting).

Sua base está com as estatísticas atualizadas? (analyze) Se não está,
execute um analyze e verifique, com o explain, se o custo diminuiu ou mudou.
O custo presumido pelo plano de execução não chega nem perto da execução
real.
As funções que você utiliza estão com a volatilidade correta?

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Bernard Rodrigues Araujo]

2016-01-14 19:11 GMT-02:00 Fábio Telles Rodriguez <fabio.tel...@gmail.com>:

> Acho que tenho hoje praticamente a mesma opinião de 10 anos atrás quando
> escrevi isso:
>
> http://savepoint.blog.br/inteligncia-em-bancos-de-dados/
>
> Vejam se concordam.
>

Eu concordo.

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

Re: [pgbr-geral] Query - Construction

[Rafael Fialho]

>
> ** Lembre-se que os IDS são representacões das árvores...*
> *Se 1 diretório tem mais de uma coisa, então haverá mais de um ítem com
> aquele ID.*
>
> *Tenho que destinguir eles nos campos...*
>

Sim, tranquilo, mas há algo errado.
Valeu pelo ajuste nas respostas, com certeza todo mundo agradece, mantém a
lista bem mais organizada e facilita muito a leitura do histórico.
Você chegou a checar a volatilidade das funções, como comentei?
Elas estão stable/immutable? Usa-se volatile apenas quando há alterações
dos dados, como comandos DML, etc..
Isso poderia ser um dos motivos.
Em seguida, quando tiver mais tempo, vou ver a query com calma e tento
ajudar melhor.

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

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Rafael Bernard Rodrigues Araujo]

Talvez porque a definição do modelo de desenvolvimento acabe ficando na mão
do time de desenvolvimento mesmo.
Mas funciona muito bem com as regras no banco. Também funciona bem na
aplicação.


--
Rafael Bernard Rodrigues Araújo
about.me/rafaelbernard

2016-01-14 18:25 GMT-02:00 Saraiva Silva <matheus.sara...@gmail.com>:

> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é
> quase unanimidade entre desenvolvedores a contrariedade em deixar as regras
> de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito.
>
> ___
> 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] Regras de negocio no banco ou na aplicação

[Rafael Bernard Rodrigues Araujo]

2016-01-14 18:43 GMT-02:00 Rogerio Carvalho <carvalho.roger...@gmail.com>:

>
> Outro fato que impede a ida de regras de negócio para o banco reside
> na falta de preparo dos desenvolvedores em conhecer melhor as linguagens de
> manipulação de dados e deixar para os softwares especialistas a
> manipulação, tipo Hibernate, e como consequência perde-se na performance
> pois isto traz um padrão de codificação que nem sempre é a melhor.
>

E outro fator em que a escolha de usar o banco de dados nem é considerada é
que é muito comum o banco de dados ficar na mão do "desenvolvedor que tem
mais facilidade com o banco" ou então na responsabilidade um estagiário.

É muito comum, infelizmente.

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

[Rafael Fialho]

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

Re: [pgbr-geral] Base de dados de CEP do Brasil.

[Rafael Fialho]

Em 3 de janeiro de 2016 20:03, Gustavo Neto 
escreveu:

> Caros,
>
> Os senhores teriam a base de dados de CEP do Brasil. Pesquisei, mais os
> melhores são caros.
>

O sistema SIHAIH01, do DATASUS, possui uma base de dados de CEPs em
firebird, de repente seria bacana dar uma olhada.

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

Re: [pgbr-geral] DBlink

[Rafael Fialho]

2015-12-01 23:48 GMT-02:00 Antonio Cesar :

> Boa Noite,
>
> estou tentando criar o dblink "CREATE EXTENSION dblink" e ocorre o
> seguinte erro:
>
> ERROR:  could not access file "$libdir/dblink": No such file or directory


Você já realizou a instalação da contrib?
Há um passo antes de tentar criar a extensão se você está usando linux.

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

Re: [pgbr-geral] Insert antes de raise exception

[Rafael Fialho]

Em 24 de novembro de 2015 23:08, Danilo Silva 
escreveu:

> ​Fiz um teste conforme indicado, mas a dúvida pairou sobre o RETURN pois
> como é para trigger, então o return da chamada da função​
>
> ​é um TRIGGER​, então minha função ficou assim:
>
> EXCEPTION WHEN OTHERS THEN
> INSERT INTO tabela_log...;
> RETURN NULL;
> END;
>
> Até aqui beleza, mas a questão é que preciso mostrar a exceção na tela
> da aplicação, pois do jeito que fiz e mostrei aqui, quando faço o insert, a
> aplicação entende que a instrução deu certo (apesar de retornar 0 linhas
> afetadas, porém sem erros).
>

Uma alternativa é usar o raise notice (exemplo em [1]), antes ou depois de
realizar o insert, e tratar as mensagens no seu driver de conexão, é o que
faço em alguns casos.

[1] - http://www.postgresql.org/docs/current/static/plpgsql-structure.html

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

Re: [pgbr-geral] Base corrompida

[Rafael Fialho]

Em 25 de novembro de 2015 09:56, Bruno Pio  escreveu:

> A primeira coisa é descobrir que objeto é esse:
>>
>> 1) Descobrir qual base de dados:
>>
>> SELECT datname FROM pg_database WHERE oid = 10564368
>>
>>
>> 2) Conectar na base descoberta acima e descobrir o objeto problemático:
>>
>> SELECT * FROM pg_class WHERE relfilenode = 106824370
>>
>>
> Fabrízio, obrigado pelo retorno
>
> Segue o retorno do SELECT * FROM pg_class WHERE relfilenode = 106824370
>
>
> "relname";"relnamespace";"reltype";"reloftype";"relowner";"relam";"relfilenode";"reltablespace";"relpages";"reltuples";"relallvisible";"reltoastrelid";"reltoastidxid";"relhasindex";"relisshared";"relpersistence";"relkind";"relnatts";"relchecks";"relhasoids";"relhaspkey";"relhasrules";"relhastriggers";"relhassubclass";"relfrozenxid";"relacl";"reloptions"
>
>
> "pg_seclabel";"11";"11023";"0";"10";"0";"106824370";"0";"0";"0";"0";"3598";"0";"t";"f";"p";"r";"5";"0";"f";"f";"f";"f";"f";"105415502";"{=r/postgres}";""
>
> Não ficou muito visual, mas acho que dá para entender, o de cima são as
> colunas e abaixo os valores respectivos.
>
> Alguma sugestão do que eu posso fazer?
>

Você possui security labels em sua base?
Caso não possua, e talvez exista uma solução bem melhor que não estou
habituado, poderia buscar qual filenode, em outro cluster, representa esta
tabela, buscando pelo relname, e copiar o determinado arquivo renomeando se
necessário. Ao menos para efetuar o backup lógico deveria ser suficiente, a
não ser que esteja faltando outras relações, mas isso você só saberá ao
contornar esta.

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

Re: [pgbr-geral] Base corrompida

[Rafael Fialho]

Em 25 de novembro de 2015 10:44, Bruno Pio  escreveu:

> Você possui security labels em sua base?
>> Caso não possua, e talvez exista uma solução bem melhor que não estou
>> habituado, poderia buscar qual filenode, em outro cluster, representa esta
>> tabela, buscando pelo relname, e copiar o determinado arquivo renomeando se
>> necessário. Ao menos para efetuar o backup lógico deveria ser suficiente, a
>> não ser que esteja faltando outras relações, mas isso você só saberá ao
>> contornar esta.
>>
>> []'s
>>
>
>
> Não possuo security labels.
>
> Eu tentei fazer exatamente isso, busquei pelo relname em outro cluster e
> encontrei o filenode. Copiei o arquivo, renomeei para o filenode da base
> problemática e tentei colocar o arquivo dentro da pasta da base, mas o
> Windows me retorna a seguinte mensagem:
>
> Erro inesperado impede a operação. Anote o código de erro, que poderá ser
> útil se você obtiver ajuda adicional para resolver o problema
> Erro 0x80070570: o arquivo ou pasta está corrompido e ilegível.
>
> Vou tentar fazer a cópia da $PGDATA para outro HD para tentar fazer esse
> processo.
>
> Obrigado!
>

Nada, à disposição. Espero que se alguém tiver uma solução mais bacana, mas
que não estou familiarizado, que se responda também. Aprendizado pra todos.

Espero que consiga resolver o seu problema. Neste sentido de HD, talvez
seria interessante até detectar os motivos dos possíveis corrompimentos,
sendo que este não está descartado..

Depois nos conte como ficou a situação!

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

Re: [pgbr-geral] Base corrompida

[Rafael Fialho]

Em 25 de novembro de 2015 12:00, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
>
> Ninguém até agora respondeu o essencial (parece óbvio, mas vai que não tá
> na sua cabeça):
> Restaure seu backup e siga a produção. Base corrompida é evento raro mas,
> quando acontece, causa danos enormes como perda de dados e enorme perda de
> tempo pra achar pelo em ovo. No Windows os pêlos costumam ser mais rebeldes.
>

Acontece que o mesmo também não consegue gerar o backup, Flavio.
Por isso o tópico não foi para este lado ainda, visto também que a dúvida
do colega refere-se a conseguir recuperar esta base, não a como voltar com
o seu ambiente de produção, se é que está em produção e se é que é crítico,
pois nada foi informado.

[]'s
___
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 2015

[Rafael Fialho]

Em 23 de novembro de 2015 15:53, Sebastian Webber 
escreveu:

>
>
> Em 23 de novembro de 2015 14:22, Fernando Ike 
> escreveu:
>
>> Olá,
>>
>>   Gostaria de agradecer à todo que fizeram acontecer a Conferência
>> PostgreSQL Brasil 2015, dos participantes, palestrantes e organização.
>> Especialmente à organização por realizar o evento. :)
>>
>
> :D
>
>
>>
>>   Espero que ano que vem ocorra o evento novamente, afinal serão 10
>> anos!
>>
>
> Quando será que podemos falar em pgbr2016? eu to interessado em ajudar. :D
>

+1!

[]'s
___
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

[Rafael Fialho]

Em 24 de novembro de 2015 13:36, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2015-11-24 8:43 GMT-02:00 Antonio Cesar :
> > Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar
> para
> > uma maquina windows, alguem tem algum exemplo?
>
> Use o cygwin.
>

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

Re: [pgbr-geral] REF: Lendo tipo Bytea

[Rafael Fialho]

Em 23 de novembro de 2015 16:34, Paulo 
escreveu:

> Olá Pessoal,
>
>
>
> Tenho um campo tipo bytea, nele gravo um conteúdo XML.
>
> Quando leio este conteúdo localmente retorna OK, porem em produção no
> servido web ele retorna em Hexa.
>
>
>
> Alguém pode dar uma dica ?
>

Verifique o parâmetro bytea_output de ambos os servidores. Creio que sejam
servidores/clusters distintos, correto?
O comando pode ser executado via psql mesmo: show bytea_output;
Provavelmente um deles deve ser escape e o outro hexa. Vale checar também
as versões, pois não tenho certeza de qual delas implementa o output em
hexadecimal como default.

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

Re: [pgbr-geral] Migrar 8.0 para 9.3

[Rafael Fialho]

>
> Pessoal,
>
>
É possível migrar um banco na versão 8.0.15 diretamente para a versão 9.3
> ou 9.4?
>

Sim. Mas é necessário observar que todas as conversões explícitas não
existirão mais. Consultas que comparam campos integer com varchar, por
exemplo, sem fazer cast, não irão funcionar. Operações com like/ilike em
campos inteiros também deixam de funcionar, etc..
Para migrar você deve realizar o dump com a versão de destino, ou seja, 9.3
ou 9.4.


> Tentei efetuar na 9.3, porém apresentou alguns erros, como por exemplo:
>
> CREATE FUNCTION lo_in(cstring) RETURNS lo LANGUAGE c IMMUTABLE STRICT AS
> '$libdir/lo', 'lo_in';
> ERRO:  não pôde encontrar função "lo_in" no arquivo
> "/usr/lib/postgresql/9.3/lib/lo.so"
>

Você efetuou o backup conforme descrito acima?


>
> Algumas tabelas possuem campos do tipo "large object" para guardar
> imagens, será necessário efetuar alguma configuração do lado da versão 9.3,
> ou devo instalar algo?
>
>
Sim, o parâmetro bytea_output para escape, e normalmente
standard_conforming_strings para off.

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

Re: [pgbr-geral] [off-topic] Only NoSQL

[Rafael Fialho]

>
> E muitas não fazem muito bem. Ainda bem que algumas já se perceberam isso,
> vide o caso Diaspora:
> http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
>

Artigo muito bom e bastante explicativo, em ambos pontos de vista. Cada um
é livre pra ler (ou não) e tirar suas próprias conclusões.
É dever de cada um explorar todas as opções de informação possíveis, e
diversificar estas fontes. Fato disso é que, no Brasil, "metade" da
população não acredita no que não passa na TV, o que é absurdo pra muitos
que já aprenderam a ver além e explorar outras fontes, e é grande causa de
MUITOS dos problemas que temos, mas isso já é assunto para outro off-topic.

De qualquer forma, discussão muito interessante e de grande valia. Espero
que todos entendam que é uma discussão saudável e que busca ajudar 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] could not send data to client: Conexão fechada pela outra ponta

[Rafael Fialho]

>
> O cliente reclama que o sistema perde conexão com o banco de dados sem
> motivo aparente, não é possível simular o problema (nem eu nem ele
> conseguimos reproduzir no momento que queremos), acontece muitas vezes
> em intervalo de minutos, outras vezes passam-se horas até um erro
> ocorrer... Apenas algumas estações apresentam o problema.
>

O problema é intermitente, mas existe algum marco (data) do início deste
problema?
Caso exista, e não tenha ocorrido alterações na aplicação, creio que já
ocorra o descarte da mesma como causa do problema, ou mesmo um
encaminhamento direto à alguma alteração que tenha sido realizada na mesma.
Já houve tentativa de diagnóstico de algum problema de rede, perda/colisão
de pacotes e etc.?

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

Re: [pgbr-geral] Consultar valores através da tabela de sistema.

[Rafael Fialho]

>
> Eu realmente precisaria fazer isso dinamicamente.
>

Isso incluiria utilizar PL's? Acredito que seja viável utilizando PL's,
apesar de bastante trabalhoso. Mas tendo essa possibilidade, poderia também
montar os SQLs de forma dinâmica, utilizando o catálogo para buscar as
relações e atributos das mesmas. Assim só será preciso definir as relações
de modo que seja fácil adicionar ou removê-las. Talvez por parâmetro,
talvez por constantes, etc..

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

Re: [pgbr-geral] Consultar valores através da tabela de sistema.

[Rafael Fialho]

>
> Bom dia a todos!!
>

Bom dia!


> Eu tenho em todas as minhas tabelas um campo para data de cadastro, tipo:
> (cliente_datacad, fornecedor_datacad etc). Eu gostaria de obter o maior
> valor entre todos esses campos(Max(campo)). Tem como obter isso através da
> tabela de sistema?? Não gostaria de escrever um select com vários
> subselects para fazer isso.
>

A princípio, tabela que conheço que grava valores dos atributos de tuplas
seria a pg_statistic, alimentada pelo analyze. Porém, creio que a busca de
valores dessa tabela, que armazena os valores dos atributos em campos do
tipo anyarray, serja mais trabalhosa do que realizar querys específicas,
pois terás de determinar o número do atributo, o oid das relações e etc.,
além de varrer os arrays.

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

Re: [pgbr-geral] View (Master Detail)

[Rafael Fialho]

>
> Acho que assim resolve
>
> SELECT
> dep.*
> FROM tmp_associado ass
> JOIN tmp_associado dep
>   ON dep.cod_associado = ass.cod_associado
> AND ass.seq_fam = 0
> ORDER BY ass.nome, (dep.seq_fam = 0) DESC, dep.nome;
>
> ... ainda com um plus de ordenar os dependentes na ordem alfabética tmb!
>

Solução beeem melhor! Pra funcionar conforme pretendido, basta trocar
o dep.nome
por dep.seq_fam.

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

Re: [pgbr-geral] View (Master Detail)

[Rafael Fialho]

Em 26 de outubro de 2015 09:35, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

> >>Solução beeem melhor! Pra funcionar conforme pretendido, basta trocar o 
> >>dep.nome
> por dep.seq_fam.
>
> >>[]'s
>
>
> Melhor impossível! Muito obrigado, Rafael!
>

A solução foi do Marcone, só comentei a questão da ordenação porque afetava
os dependentes..
Mas bom que está tudo em ordem agora.

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