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

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

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

[Rafael Fialho]

>
> Bom dia, Rafael. Obrigado pela sugestão.
> Estava mesmo com pl/sql em mente, mas uma solução mais limpa (como você
> disse) seria melhor.
>

Seria algo tipo isso (não ficou nada elegante, ao meu ver, mas foi o que
consegui fazer rapidamente):

with associados(ordem, cod_associado, seq_fam, nome) as
(
select
case
when seq_fam = 0 then
rank() over (order by nome)
else
null
end as ordem
, cod_associado
, seq_fam
, nome
from
associados
order by
cod_associado
, seq_fam
, nome
)
select
case
when ordem is null then
(select a.ordem from associados a where a.cod_associado =
ascd.cod_associado and a.seq_fam = 0 and a.ordem is not null)
else
ordem
end as ordem
, cod_associado
, seq_fam
, nome
from
associados ascd
order by
1
, cod_associado
, seq_fam

Fica de ideia caso queiras otimizar e realizar de uma melhor forma.

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

>
> Fiz com Inner Join mas o resultado não foi o mesmo...
> Alguma sugestão?
>

Com certeza ainda existe uma solução mais elegante e performática, mas a
sexta-feira, após semana de correria, não me permite enxergar mais. Possui
índices que satisfaçam as pesquisas?
Se possível poste o plano de execuçã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] [off-topic] Como está a situação da Porto Alegre da PGBR 2015?

[Rafael Fialho]

>
> Pessoal, peço informações aos organizadores da pgbr 2015 presentes nesta
> comunidade, sobre a situação da área de hotéis e do evento, em vistas das
> últimas notícias sobre a cidade.
>

A área onde será realizada o evento é bem à parte de onde estão localizados
os problemas.
A cidade em si não está com tantos problemas quanto a região metropolitana.
Os alagamentos são mais à zona sul, enquanto o PGBR será realizado na zona
"nordeste" da cidade.


> Como estou intencionando ir ao evento e a viagem será de muito longe
> (Sergipe), gostaria de saber como está a cidade para nos receber, bem como
> a possibilidade de 'turistar' por lá nos dias do evento.
>

Os locais mais "turistados" também estão em áreas pouco afetadas, e
provavelmente tudo esteja bem mais organizado até a data do evento, pois
foram eventos muito atípicos (em 40 anos não tínhamos problemas como esse)
e muita coisa já está sendo ajustada e recebendo os devidos ajustes para
prevençã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] Erro pg_restore

[Rafael Fialho]

>
> Fiz remoto o backup, usando o servidor que tem o 9.4 e depois tentei
> restaurar deu mesmo erro...
>
> D:/Program Files/PostgreSQL/9.4/bin\pg_restore.exe --host localhost --port
> 5432 --username "postgres" --dbname "db" --no-password  --data-only --table
> vendas --schema public --verbose "E:\vendas.backup"
>

Estás fazendo a restauração como data-only por algum motivo específico? Não
existe diferença na estrutura da tabela na base de origem e na base de
destino?
Já tentou restaurar a tabela inteira?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro pg_restore

[Rafael Fialho]

>
> Pessoal,
>
> estou com problema ao dar um pg_dump e restaurar pg_restore, exportando do
> 9.3 e importando no 9.4
>

Você realizou o restore com o binário da versão 9.4, mas utilizou o pg_dump
de qual versão?
Para realizar este tipo de migração você deve realizar o dump com o binário
da versão de destino, além de utilizar o pg_restore da versão de destino
também.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro pg_restore

[Rafael Fialho]

>
> é utilizei diferente, 9.3 -> 9.4 , será que pode ser isso?  mas ai qual
> procedimento?  tenho os 2 bancos rodando em servidores diferentes...
>

Sendo ou não, o correto é utilizar a versão de destino, no caso utilizar o
pg_dump da versão 9.4.
Utilize o pg_dump 9.4 para fazer backup remoto, se possível, ao invés de
realizar o backup com os binários da versão 9.3 no próprio servidor 9.3.

[]'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] ENC: REF: FUNCAO IFNULL.

[Rafael Fialho]

Em 8 de setembro de 2015 10:50, PAULO 
escreveu:

> Olá Pessoal,
>
>
>
> Estou convertendo uma APP Mysql e preciso substituir a função IFNULL:
>
>
>
> Na APP esta assim:
>
> UPDATE parametro_nfe  SET id_lote = (IFNULL(id_lote,0) + 1);
>
>
>
> Estou tentando:
>
> UPDATE parametro_nfe  SET id_lote = (Coalesce(id_lote, 0, + 1));
>

O zero seria para caso o parâmetro esteja em branco, certo?
A ordem correta, se for este o caso, seria "UPDATE parametro_nfe  SET
id_lote = (coalesce(id_lote, 0) + 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] PGBR2015 - Ajuda com arte para camisetas, canecas, etc

[Rafael Fialho]

Em 21 de agosto de 2015 11:52, Fabrízio de Royes Mello 
fabri...@timbira.com.br escreveu:

 Pessoal,

 Estamos precisando MUUUITO de ajuda para criar algumas artes para o
 evento.

 Se alguém puder ajudar nisso ficaremos muito gratos. Estamos com
 orçamento muito apertado e não temos $$ para contratar alguém pra fazer
 isso.

 Abraço,


Tens padrões dos eventos passados, para termos uma ideia?
Poderia dar uma força nisso se já tiveres ideia de quais itens serão
confeccionados, entre objetos, cores 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] LIBERAR TODOS IP

[Rafael Fialho]

 É isso mesmo José, lembrando que após as alterações é necessário restartar
 o pg.


Seria isso, mas só pra salientar, não é necessário reiniciar o postgres. Um
reload nas configurações já é suficiente após as alterações, e o mesmo pode
ser feito tanto por query com a função pg_reload_conf() quanto pelo pg_ctl,
na opção reload indicando o diretório de dados.

[]'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] Pesquisa rápida com os DBAs da lista

[Rafael Fialho]

Em 11 de agosto de 2015 17:10, Fábio Telles Rodriguez 
fabio.tel...@gmail.com escreveu:

 Senhores, quem puder responder em PVT ou aqui na lista, eu agradeço. A
 questão que eu quero abordar rapidamente é como as pessoas se tornam um DBA
 na sua carreira de TI.

 Responda, como iniciou sua carreira de DBA???

 A) Eu era um sysadmin e precisavam de alguém para cuidar do banco de dados
 XPTO na empresa.
 B) Eu era um desenvolvedor e precisavam de alguém para cuidar do banco de
 dados XPTO na empresa.

Check.

 C) Eu era o gestor de um grupo de TI, e precisavam de alguém para cuidar
 do banco de dados XPTO na empresa.
 D) Eu já gostava de banco de dados e direcionei minha carreira para isso

Check.

 E) Outros: qual?


A pedidos, respondendo na lista.
[]'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] pgagent

[Rafael Fialho]

Em 1 de julho de 2015 20:36, Douglas Fabiano Specht 
douglasfabi...@gmail.com escreveu:



 Em 1 de julho de 2015 20:02, Douglas Fabiano Specht 
 douglasfabi...@gmail.com escreveu:



 Em 1 de julho de 2015 17:22, Rafael Fialho rafafial...@gmail.com
 escreveu:

 Em 1 de julho de 2015 17:07, Douglas Fabiano Specht 
 douglasfabi...@gmail.com escreveu:

 Pessoal,
 estou implementando via pgagent para disparar uma function de 1 em 1
 minuto,


 Precisamos entender como foi realizada a instalação.
 Estás com o processo pgagent rodando no seu servidor, e devidamente
 configurado?
 A aba Jobs aparece em seu pgAdmin?

 ocorre que o esse job não está sendo disparado, tentei recriar e gerou o
 seguinte sql:

 INSERT INTO pgagent.pga_job (jobid, jobjclid, jobname, jobdesc,
 jobenabled, jobhostagent)
 SELECT JobId, jcl.jclid, 'enviaMensagem', '', true, 'localhost'
   FROM pgagent.pga_jobclass jcl WHERE jclname='Data Summarisation';


 INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc,
 jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr)
  SELECT StpId, JobId, 'reenviaMensagem', '', true, 's', 'f',
 'select smsdk.reenviaMensagem();', 'smsdk', '';
 INSERT INTO pgagent.pga_schedule (jscid, jscjobid, jscname, jscdesc,
 jscminutes, jschours, jscweekdays, jscmonthdays, jscmonths, jscenabled,
 jscstart, jscend)
 VALUES(SchId, JobId, 'reenviaMensagem', '',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}', '{t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t}', true, '2015-07-01 00:00:00', '2020-07-01
 00:00:00');


 onde eu acompanho o historico de execução? pois no pgadmin em
 statistics esta tudo em branco.


 Na própria aba Jobs do pgAdmin é possível visualizar os jobs criados e
 verificar quando foi a última tentativa de execução, se ocorreu sucesso ou
 falha, etc.. Na tabela pgagent.pga_job também existe o campo joblastrun
 para determinar quando foi a última vez que o job foi executado.
 No seu caso, creio que ele não está sendo executado por falta de
 inicialização e configuração do processo pgagent.

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


 Rafael
 consegui pegar o log, acho que é algo sobre autenticação:
 WARNING: Failed to create new connection to database
 'mensagem':'fe_sendauth: no password supplied'

 no debian onde configuro o pgpass? soachei referencia para windows..


 --

 Douglas Fabiano Specht


 Encontrei..
 no /home/postgres/.pgpass
 ja funcionando


Exatamente.. normalmente, por segurança, creio que seja uma das melhores
formas, mas aí é outra discussão.
Em ambientes de testes, o trust para conexões locais já resolve.

[]'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] pgagent

[Rafael Fialho]

Em 1 de julho de 2015 17:07, Douglas Fabiano Specht 
douglasfabi...@gmail.com escreveu:

 Pessoal,
 estou implementando via pgagent para disparar uma function de 1 em 1
 minuto,


Precisamos entender como foi realizada a instalação.
Estás com o processo pgagent rodando no seu servidor, e devidamente
configurado?
A aba Jobs aparece em seu pgAdmin?

ocorre que o esse job não está sendo disparado, tentei recriar e gerou o
 seguinte sql:

 INSERT INTO pgagent.pga_job (jobid, jobjclid, jobname, jobdesc,
 jobenabled, jobhostagent)
 SELECT JobId, jcl.jclid, 'enviaMensagem', '', true, 'localhost'
   FROM pgagent.pga_jobclass jcl WHERE jclname='Data Summarisation';


 INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc,
 jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr)
  SELECT StpId, JobId, 'reenviaMensagem', '', true, 's', 'f', 'select
 smsdk.reenviaMensagem();', 'smsdk', '';
 INSERT INTO pgagent.pga_schedule (jscid, jscjobid, jscname, jscdesc,
 jscminutes, jschours, jscweekdays, jscmonthdays, jscmonths, jscenabled,
 jscstart, jscend)
 VALUES(SchId, JobId, 'reenviaMensagem', '',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}', '{t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t}', true, '2015-07-01 00:00:00', '2020-07-01
 00:00:00');


 onde eu acompanho o historico de execução? pois no pgadmin em statistics
 esta tudo em branco.


Na própria aba Jobs do pgAdmin é possível visualizar os jobs criados e
verificar quando foi a última tentativa de execução, se ocorreu sucesso ou
falha, etc.. Na tabela pgagent.pga_job também existe o campo joblastrun
para determinar quando foi a última vez que o job foi executado.
No seu caso, creio que ele não está sendo executado por falta de
inicialização e configuração do processo pgagent.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Rafael Fialho]

Em 20 de abril de 2015 10:55, Vilson vossiste...@ibest.com.br escreveu:

   Estou usando: Postgresql 9.4
 Windows 7 professional
 Computador desktop i3 com 4GB de memórioa e HD 500
 GB
 vb2010

 Estava funcionando ok até que do nada ficou lento demais, chegando ao
 ponto da aplicação parar. Faço uma seleção com PGAdminIII e também fica
 demorada mas não para.
 Não foi feito nenhuma atualização, e simplesmente fica lenta ou para de
 funcionar. Tem algo a ver com o banco de dados ou o problema é do
 computador. Já fiz o Vacum, reinstalei o banco de dados, reinstalei a
 aplicação, mas nada funciona.


Nenhuma de suas intervenções, ao meu ver, poderia resolver este problema.
Eexecute um analyze em sua base de dados e tente novamente. Caso não
resolva o problema, informe o plano de execução de sua query utilizando o
explain analyze.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Cast explicito nos parâmetros de funções

[Rafael Fialho]

Em 16 de abril de 2015 16:06, Matheus Saraiva matheus.sara...@gmail.com
escreveu:

 Ao chamar uma função que criei, estou sendo obrigado a usar cast
 explicito nos parâmetros. Por exemplo, em uma função que espera receber
 (varchar, integer, smallint, bigint, date) eu estou sendo obrigado a
 castar o tipo na chamada da função. Exemplo

 select funcTeste('Teste'::varchar, 1, 3::smallint, 10::bigint,
 NULL::date);

 Caso contrario os parâmetros não são reconhecidos. Alguma maneira de
 mudar isso?


Pode informar o erro retornado sem os casts, por gentileza? Quando ocorre o
erro, o Postgres informa qual a função que não conseguiu localizar,
informando os tipos que espera localizar a função.
O problema provavelmente ocorre porque números soltos (normalmente) são
tratados como integer, a não ser que excedam a capacidade de valores
integer, neste caso são tratados como bigint. Sendo assim, o problema é
causado pelos parâmetros smallint e bigint.

O erro deve ser que não conseguiu localizar uma função funcTeste(unknown,
integer, integer, integer, unknown), ou algo assim.
Se for isso, poderias fazer um override ..integer, integer, integer.. que
chame a função com os casts, caso contrário, creio que seja um erro da
aplicação não tratar e não realizar os casts, pois é a forma que assegura
que a função correta está sendo chamada.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Cast explicito nos parâmetros de funções

[Rafael Fialho]

Em 16 de abril de 2015 16:34, Matheus Saraiva matheus.sara...@gmail.com
escreveu:

 (...)
 Como seria o override?


Para o segundo caso que mostraste agora, não sei, pois aparentemente os
parâmetros são diferentes.
Para o primeiro, provavelmente algo como funcTeste(varchar, integer,
integer, integer, date)

Dentro desta função você chamaria a correta passando os parâmetros com os
casts: return funcTeste($1::varchar, $2::integer, $3::smallint, $4::bigint.
$5::date);

Algo mais ou menos assim, com tratamentos, se necessário.

Na minha aplicação as funções sempre normalmente chamadas com casts, então
não costumo utilizar overrides.
Talvez alguém possa contribuir com outra solução.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Cast explicito nos parâmetros de funções

[Rafael Fialho]

Em 16 de abril de 2015 17:04, Matheus Saraiva matheus.sara...@gmail.com
escreveu:

 Em Qui, 2015-04-16 às 16:53 -0300, Rafael Fialho escreveu:
  Em 16 de abril de 2015 16:34, Matheus Saraiva
  matheus.sara...@gmail.com escreveu:
  (...)
  Como seria o override?
 
 
  Para o segundo caso que mostraste agora, não sei, pois aparentemente
  os parâmetros são diferentes.
  Para o primeiro, provavelmente algo como funcTeste(varchar, integer,
  integer, integer, date)
 
 (...)
 Minha função real recebe (varchar, date, integer, integer, bigint,
 smallint)

 Isso seria uma recursão ou eu teria que criar duas funções separadas, uma
 com e outra sem o cast?


Normalmente seria pra outro fim, como para atribuir defaults para os
parâmetros, não pra este.
Precisas criar duas funções distintas, uma com os parâmetros normais e a
outra que chamará a função principal realizando os casts.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Servidor PostgreSQL não sobe

[Rafael Fialho]

2015-04-07 8:19 GMT-03:00 Pedro B. Alves pedroalve...@gmail.com:

 Pessoal reiniciei o servidor de produção e quando tento subir o pg ele dá
 o seguinte erro:


 $ /usr/pgsql-9.3/bin/postgres -D /var/lib/pgsql/data/
 FATAL:  database files are incompatible with server
 DETAIL:  The data directory was initialized by PostgreSQL version 8.4,
 which is not compatible with this version 9.3.4.


O erro refere-se ao diretório /var/lib/pgsql/data/, não ao diretório
/usr/pgsql-9.3/bin/.
Os binários e a pasta data estão em locais diferentes? Se não, arriscaria
em dizer que o diretório data seria /usr/pgsql-9.3/data.

[]'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] Verificar tabelas que precisam de VACUUM

[Rafael Fialho]

Em 23 de março de 2015 16:13, Tiago José Adami adam...@gmail.com escreveu:

 Trabalho com um determinado banco de dados para um aplicativo
 científico com dados sensoriais (não sei como ele funciona, só cuido
 das informações no SGBD) que possui acesso constante a algumas tabelas
 24x7. O autovacuum parece não estar encontrando uma janela disponível
 (o espaço utilizado em disco diminui
 pouco ou nada comparado a um VACUUM explícito), então me obrigo a
 colocar um agendamento no cron toda madrugada, deixando o banco
 temporariamente inoperante.


Você está verificando o funcionamento do vacuum através de espaço em disco?
O vacuum comum não reescreve as tabelas, logo todo espaço utilizado pelas
mesmas não é liberado, a não ser que seja feito o vacuum full. Qual o
comando para vacuum você está executando de forma explícita?



 Há como saber se o autovacuum está sendo eficiente? Tipo: um SELECT
 que mostre quais tabelas precisam de VACUUM?


Existe uma função chamada pg_stat_get_dead_tuples, que recebe o oid da
relação e que pode te mostrar essa informação. Além do analyze verbose, que
também mostra o número aproximado de tuplas e de tuplas mortas.



 Dessa forma eu faria uma checagem e executaria somente quando necessário.

 PostgreSQL 9.3.5.


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

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

Re: [pgbr-geral] Como fazer esse select no postgresql?

[Rafael Fialho]

Em 17 de março de 2015 11:36, Douglas Listas douglas.gru...@gmail.com
escreveu:

 Bom dia!

 Galera, esse select:

 select cpf_comprador, list(distinct nome_comprador), sum(vlr) from
 vendas group by cpf_comprador;
 Roda em um banco Sybase (Watcom)...

 Como posso reescrever ele para Postgresql?


Descreva melhor o seu conjunto de dados e o resultado esperado, por
gentileza, principalmente para esta parte list(distinct nome_comprador),
de preferência com a formatação.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Rafael Fialho]

Em 13 de março de 2015 15:03, Rafael Fialho rafafial...@gmail.com
escreveu:

 Em 13 de março de 2015 12:07, Junior Miranda flmirandajun...@gmail.com
 escreveu:

 Boa tarde a todos

 Estou com problemas de lentidão em uma consulta select * from. A tabelas
 possui 20 mil registros, e estou tentando criar um cursor. O problema é que
 não estou conseguindo
 retornar os dados, fica informando que a query está sendo executada e não
 sai disso. O objetivo é agilizar o retorno destes registros.

 ()
 $BODY$
LANGUAGE 'plpgsql' VOLATILE;


 Sei que pode não fazer diferença, mas sempre é motivo de divergências no
 banco de dados e loucuras em geral durante a implementação, mas você já
 tentou utilizar o tipo STABLE ao invés de VOLATILE?
 Sua função não faz modificações no banco, portanto ela não é volátil.

 Pode não dar em nada, porque já vi os tipos de função apresentar
 diferentes comportamentos em diferentes bancos/quantidade de
 registros/estatísticas, mas né, não custa fazer da forma correta.

 []'s


Favor ignorar a última mensagem.. Fiz o teste aqui e não resolve o
problema. O problema está no fetch mesmo, que não incrementa o cursor e
fica dando voltas no mesmo registro, aparentemente.
Já cogitaste utilizar um type, fazendo uma função com tipo de retorno SETOF
deste type?
Deste modo funcionaria mais ou menos como você quer, porém realizando um
loop em um record.

[]'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] Consulta lenta

[Rafael Fialho]

Em 13 de março de 2015 12:07, Junior Miranda flmirandajun...@gmail.com
escreveu:

 Boa tarde a todos

 Estou com problemas de lentidão em uma consulta select * from. A tabelas
 possui 20 mil registros, e estou tentando criar um cursor. O problema é que
 não estou conseguindo
 retornar os dados, fica informando que a query está sendo executada e não
 sai disso. O objetivo é agilizar o retorno destes registros.

 ()
 $BODY$
LANGUAGE 'plpgsql' VOLATILE;


Sei que pode não fazer diferença, mas sempre é motivo de divergências no
banco de dados e loucuras em geral durante a implementação, mas você já
tentou utilizar o tipo STABLE ao invés de VOLATILE?
Sua função não faz modificações no banco, portanto ela não é volátil.

Pode não dar em nada, porque já vi os tipos de função apresentar diferentes
comportamentos em diferentes bancos/quantidade de registros/estatísticas,
mas né, não custa fazer da forma 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] Estatística - Tempo médio total de queries

[Rafael Fialho]

Em 3 de março de 2015 17:15, Cleiton Luiz Domazak cleitondoma...@gmail.com
escreveu:

 (...)
 Ou se tiver alguma outra ferramenta que me de esse tipo de informação sem
 que seja por LOG seria perfeito, pois hoje o log está configurado para
 logar apenas queries acima de 100ms, o que invalida a minha estatística via
 LOG.


Faça a estatística em cima dessas queries mesmo. Concordo com o Flavio
nesse sentido, se você loga o que é mais lento, utilize estas para calcular
seu tempo médio, pois o resto só vai servir para mascarar as queries que
realmente precisam de recursos e de possível otimizaçã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] Tempo de backup

[Rafael Fialho]

Em 3 de março de 2015 13:26, Danilo Silva danilo.dsg.go...@gmail.com
escreveu:


 08 minutos = pg_basebackup -U replicador -P -c fast -v -D
 /backup/database/ -Ft​


Tente retirar a opção de formato (-Ft), para realizar o backup no modo
default (plain), e verifique se o tamanho se manteve igual ao original.

[]'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] Tempo de backup

[Rafael Fialho]

Em 3 de março de 2015 13:34, Rafael Fialho rafafial...@gmail.com escreveu:

 Em 3 de março de 2015 13:26, Danilo Silva danilo.dsg.go...@gmail.com
 escreveu:


 08 minutos = pg_basebackup -U replicador -P -c fast -v -D
 /backup/database/ -Ft​


 Tente retirar a opção de formato (-Ft), para realizar o backup no modo
 default (plain), e verifique se o tamanho se manteve igual ao original.

 []'s


Outra coisa, a comparação (16GB) contém a pasta pg_xlog? Não cheguei a ver
nenhum exemplo prático que contenha divergências como esta, mas, se for o
caso, podem estar faltando os logs de transação junto ao seu backup, e
estes podem representar a diferença em tamanho.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral