from:"luiz"




De: "José Mello Júnior" <jose.mello.jun...@gmail.com> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Sexta-feira, 3 de novembro de 2017 15:42:55 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

o que é toppsting? Não compreendi direito, se tenho dúvida sobre o 
comportamento, não devo postar aqui? 
Att 


Em 3 de novembro de 2017 13:42, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 






De: "José Mello Júnior" < jose.mello.jun...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Sexta-feira, 3 de novembro de 2017 12:09:44 

Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Este é um backup que é feito por esquema, em dois esquemas tem esse 
comportamento (um menor onde tem lo) e em outro que só tem texto mas tem 120 
tabelas carregadas, nos demais bkp (outros esquemas) funciona direitinho, por 
isso estou pedindo auxílio, não consegui visualizar onde tenho de atuar para 
evitar isso. 
Obrigado 


Em 3 de novembro de 2017 10:19, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 

BQ_BEGIN




De: "José Mello Júnior" < jose.mello.jun...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Sexta-feira, 3 de novembro de 2017 9:33:30 

Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Bom Dia, 
Faço um arquivo de lote para executar a chamada, por isso utilizei o pause de 
onde posso visualizar as mensagens do pg_dump. O término indica normal, sem 
qualquer mensagem, contudo o tamanho é diminuído para 1 Kb. 

Att 


Em 3 de novembro de 2017 08:21, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 

BQ_BEGIN

De: "José Mello Júnior" < jose.mello.jun...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 1 de novembro de 2017 18:04:41 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Coloquei até um PAUSE dentro do arquivo de lote de execução, mas não vem 
qualquer mensagem. 
Att 


Em 1 de novembro de 2017 14:34, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 

BQ_BEGIN



BQ_BEGIN

Não estou descobrindo porque o dump da base de dados está ficando com 1kb ao 
final da execução. O tamanho deveria ser aproximadamente 500Mb, e no tempo em 
que executa vejo o tamanho do arquivo ir crescendo normalmente, mas ao final o 
tamanho fica incompatível. 
Linha pg_dump: 

"C:\Program Files\PostgreSQL\9.3\bin\pg_dump.exe" --host localhost --port 5432 
--username "backup" --role "backup" --format custom --blobs --encoding 
SQL_ASCII --inserts --column-inserts --disable-dollar-quoting --verbose --file 
"C:\BKP\20171031172048000\notas.backup" --schema "notas" "gn" 

O que pode estar acontecendo? 




Você pode mandar o log da execução? Talvez ajude utilizando a opção -v 
(verbose). 


-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 


José, 

Como assim, não vem mensagem? O arquivo de log não é escrito? o pause é 
inserido dentro de qual arquivo, dentro do arquivo que realiza o backup? 

Obrigado. 



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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 
José, 

Executa um teste, cria arquivo de dump que só faz o backup de uma tabela 
pequena e coloca para logar em um arquivo de log. 
Após isso, terá mais contexto para analizar. 

Obrigado. 

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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.

Re: [pgbr-geral] postgresql.conf não encontrado




De: "Neto pr"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Sexta-feira, 3 de novembro de 2017 14:06:55 
Assunto: Re: [pgbr-geral] postgresql.conf não encontrado 



Em 3 de novembro de 2017 10:52, Flavio Henrique Araque Gurgel < 
fha...@gmail.com > escreveu: 





Em sex, 3 de nov de 2017 às 13:44, Neto pr < neto...@gmail.com > escreveu: 

BQ_BEGIN

Daniel, 
sim estava no diretorio /etc/postgresql. Sempre instalei compilando os fontes, 
por isso me perdi nessa. 

Outro problema que está ocorrendo com este parametro do postgresql.conf 

shared_preload_libraries = 'pg_stat_statements, powa, pg_stat_kcache, 
pg_qualstats' 

Ao colocar as duas bibliotecas abaixo o SGBD não sobe. Ja tentei colocar 
somente 1 delas, mas realmente as duas dão erro. 
- pg_stat_kcache 
- pg_qualstats 




BQ_BEGIN

Se alguém tiver alguma dica, será bem vinda. 

BQ_END

Eu tenho duas dicas: 
Dica 1 - pare de fazer top post, você não é mais novato 

BQ_END

OK, Sobre top post, mal ha'bito 


BQ_BEGIN

Dica 2 - mande a mensagem de erro que sai 


BQ_END


Vi no log que nao estava encontrando as bibliotecas. Apos isso, instalei os 
pacote conforme tutorial abaixo e mesmo assim nao encontrava. 
Entao copiei e colei na pasta /usr/lib/postgresql/9.6/lib/ as bibliotecas 
(arquivos *.so). 
Agora o erro que ocorre e' que a de versao incompativel, ou seja, versao do 
SGBD e' 9.6 e a biblioteca e' da versao 10.0. 
O estranho e' que segui o tutuorial e o link que passaram estava informando que 
era da versao 9.6, vejam o link do arquivo o log de erro. Ja a outra biblioteca 
da erro de copy symbol. 

== Log erro  
2017-11-03 12:00:44.445 BRST [1610] FATAL: could not access file 
"pg_stat_kcache": No such file or directory 
2017-11-03 12:00:44.445 BRST [1610] LOG: database system is shut down 
2017-11-03 12:14:52.216 BRST [1672] FATAL: incompatible library 
"/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch 
2017-11-03 12:14:52.216 BRST [1672] DETAIL: Server is version 9.6, library is 
version 10.0. 
2017-11-03 12:14:52.216 BRST [1672] LOG: database system is shut down 
2017-11-03 12:18:56.311 BRST [1729] FATAL: could not load library 
"/usr/lib/postgresql/9.6/lib/pg_qualstats.so": /usr/lib/postgresq 
l/9.6/lib/pg_qualstats.so: undefined symbol: copyObjectImpl 
2017-11-03 12:18:56.311 BRST [1729] LOG: database system is shut down 
2017-11-03 12:27:10.895 BRST [1799] FATAL: incompatible library 
"/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch 
2017-11-03 12:27:10.895 BRST [1799] DETAIL: Server is version 9.6, library is 
version 10.0. 
2017-11-03 12:27: 
 
-- 
PoWA Documentation, Release 3.1.0 
On Debian: 
apt-get install postgresql-server-dev-9.6 postgresql-contrib-9.6 
Installation 
Download powa-archivist latest release: 
wget https://github.com/dalibo/powa-archivist/archive/REL_3_1_0.tar.gz 
A convenience script is offered to build every project that PoWA can take 
advantage of: 
#!/bin/bash 
# This script is meant to install every PostgreSQL extension compatible with 
# PoWA. 

--> AQUUIII ---> wget 
https://github.com/dalibo/pg_qualstats/archive/1.0.2.tar.gz -O pg_ 
˓ 
→ 
qualstats-1.0.2.tar.gz 
tar zxvf pg_qualstats-1.0.2.tar.gz 
cd pg_qualstats-1.0.2 
(make && sudo make install) > /dev/null 2>&1 
cd .. 
rm pg_qualstats-1.0.2.tar.gz 
rm pg_qualstats-1.0.2 -rf 
--> AQUUIII ---> wget 
https://github.com/dalibo/pg_stat_kcache/archive/REL2_0_3.tar.gz -O pg_ 
˓ 
→ 
stat_kcache-REL2_0_3.tar.gz 
tar zxvf pg_stat_kcache-REL2_0_3.tar.gz 
cd pg_stat_kcache-REL2_0_3 
(make && sudo make install) > /dev/null 2>&1 
cd .. 
rm pg_stat_kcache-REL2_0_3.tar.gz 
rm pg_stat_kcache-REL2_0_3 -rf 
(make && sudo make install) > /dev/null 2>&1 
echo "" 
echo "You should add the following line to your postgresql.conf:" 
echo '' 
echo "shared_preload_libraries='pg_stat_statements,powa,pg_stat_kcache,pg_ 
˓ 
→ 
== FIM == 



BQ_BEGIN

Aí a gente vem com mais dicas quentinhas. 

[]s 
Flavio Gurgel 

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

BQ_END



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

-- 

Neto, 

Está claro no log do postgres que a versão da biblioteca é maior que a versão 
atual do postgres. 
Para isso, acesse a página e busca a versão adequada da biblioteca para sua 
versão do postgres. 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado




De: "José Mello Júnior" <jose.mello.jun...@gmail.com> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Sexta-feira, 3 de novembro de 2017 12:09:44 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Este é um backup que é feito por esquema, em dois esquemas tem esse 
comportamento (um menor onde tem lo) e em outro que só tem texto mas tem 120 
tabelas carregadas, nos demais bkp (outros esquemas) funciona direitinho, por 
isso estou pedindo auxílio, não consegui visualizar onde tenho de atuar para 
evitar isso. 
Obrigado 


Em 3 de novembro de 2017 10:19, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 






De: "José Mello Júnior" < jose.mello.jun...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Sexta-feira, 3 de novembro de 2017 9:33:30 

Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Bom Dia, 
Faço um arquivo de lote para executar a chamada, por isso utilizei o pause de 
onde posso visualizar as mensagens do pg_dump. O término indica normal, sem 
qualquer mensagem, contudo o tamanho é diminuído para 1 Kb. 

Att 


Em 3 de novembro de 2017 08:21, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 

BQ_BEGIN

De: "José Mello Júnior" < jose.mello.jun...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 1 de novembro de 2017 18:04:41 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Coloquei até um PAUSE dentro do arquivo de lote de execução, mas não vem 
qualquer mensagem. 
Att 


Em 1 de novembro de 2017 14:34, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 

BQ_BEGIN



BQ_BEGIN

Não estou descobrindo porque o dump da base de dados está ficando com 1kb ao 
final da execução. O tamanho deveria ser aproximadamente 500Mb, e no tempo em 
que executa vejo o tamanho do arquivo ir crescendo normalmente, mas ao final o 
tamanho fica incompatível. 
Linha pg_dump: 

"C:\Program Files\PostgreSQL\9.3\bin\pg_dump.exe" --host localhost --port 5432 
--username "backup" --role "backup" --format custom --blobs --encoding 
SQL_ASCII --inserts --column-inserts --disable-dollar-quoting --verbose --file 
"C:\BKP\20171031172048000\notas.backup" --schema "notas" "gn" 

O que pode estar acontecendo? 




Você pode mandar o log da execução? Talvez ajude utilizando a opção -v 
(verbose). 


-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 


José, 

Como assim, não vem mensagem? O arquivo de log não é escrito? o pause é 
inserido dentro de qual arquivo, dentro do arquivo que realiza o backup? 

Obrigado. 



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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 
José, 

Executa um teste, cria arquivo de dump que só faz o backup de uma tabela 
pequena e coloca para logar em um arquivo de log. 
Após isso, terá mais contexto para analizar. 

Obrigado. 

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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 
José, 

Por favor, para de fazer topposting. 
Sobre o backup, não faz sentido esse comportamento. 10 backups identicos, 8 
está funcionando e 2 tem problema e não gera log. 
Existe alguma coisa nesse meio que não foi falado. 

___
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.conf não encontrado




De: "Neto pr" <neto...@gmail.com> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Sexta-feira, 3 de novembro de 2017 10:44:50 
Assunto: Re: [pgbr-geral] postgresql.conf não encontrado 

Daniel, 
sim estava no diretorio /etc/postgresql. Sempre instalei compilando os fontes, 
por isso me perdi nessa. 

Outro problema que está ocorrendo com este parametro do postgresql.conf 

shared_preload_libraries = 'pg_stat_statements, powa, pg_stat_kcache, 
pg_qualstats' 

Ao colocar as duas bibliotecas abaixo o SGBD não sobe. Ja tentei colocar 
somente 1 delas, mas realmente as duas dão erro. 
- pg_stat_kcache 
- pg_qualstats 

Se alguém tiver alguma dica, será bem vinda. 

[]`s Neto 









Em 3 de novembro de 2017 05:07, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 






De: "Neto pr" < neto...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Sexta-feira, 3 de novembro de 2017 9:31:54 
Assunto: [pgbr-geral] postgresql.conf não encontrado 

Olá 

Estava tentando instalar o postgresql via este tutorial [1] para utilizar a 
ferramenta para bd Powa. 

Uso S.O. debian 8 Jessie. 

Executei: 
apt-get install postgresql-9.6 postgresql-client-9.6 postgresql-contrib-9.6 
apt-get install postgresql-9.6-powa 

Até ai tudo bem, o SGBD subiu e consigo criar tabelas etc. 

Mas não estou encontrando onde está o arquivo postgresql.conf. 
Tentei pesquisar utilizando locate postgresql.conf, más não encontra, desconfio 
que não foi criado. 
Preciso adicionar algumas bibliotecas no parametro: shared_preload_libraries 

Alguém já instalou o postgresql desta forma, e poderia informar onde pode estar 
o arquivo postgresql.conf, ou outro para configurar o parametro 
shared_preload_libraries ? 

[1] http://powa.readthedocs.io/en/latest/quickstart.html 

[]`s Neto 

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

-- 

Neto, 

antes de utilizar o locate, faça atualização do dicionário de arquivos no 
linux, com comando "updatedb". 
Sobre o postgresql.conf, ele estará dentro do diretório /etc/postgresql/... 
caso não foi modificado na instalação. 

Obrigado. 

___ 
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 

-- 


Neto, 

Analisa o arquivo de log do postgresql, o que está exibindo de mensagem após 
tentar subir o serviço? 

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] PG_DUMP - Tamanho do Arquivo resultantes está errado




De: "José Mello Júnior" <jose.mello.jun...@gmail.com> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Sexta-feira, 3 de novembro de 2017 9:33:30 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Bom Dia, 
Faço um arquivo de lote para executar a chamada, por isso utilizei o pause de 
onde posso visualizar as mensagens do pg_dump. O término indica normal, sem 
qualquer mensagem, contudo o tamanho é diminuído para 1 Kb. 

Att 


Em 3 de novembro de 2017 08:21, Daniel Luiz da Silva < daniel.si...@ipm.com.br 
> escreveu: 



De: "José Mello Júnior" < jose.mello.jun...@gmail.com > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 1 de novembro de 2017 18:04:41 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Coloquei até um PAUSE dentro do arquivo de lote de execução, mas não vem 
qualquer mensagem. 
Att 


Em 1 de novembro de 2017 14:34, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 

BQ_BEGIN



BQ_BEGIN

Não estou descobrindo porque o dump da base de dados está ficando com 1kb ao 
final da execução. O tamanho deveria ser aproximadamente 500Mb, e no tempo em 
que executa vejo o tamanho do arquivo ir crescendo normalmente, mas ao final o 
tamanho fica incompatível. 
Linha pg_dump: 

"C:\Program Files\PostgreSQL\9.3\bin\pg_dump.exe" --host localhost --port 5432 
--username "backup" --role "backup" --format custom --blobs --encoding 
SQL_ASCII --inserts --column-inserts --disable-dollar-quoting --verbose --file 
"C:\BKP\20171031172048000\notas.backup" --schema "notas" "gn" 

O que pode estar acontecendo? 




Você pode mandar o log da execução? Talvez ajude utilizando a opção -v 
(verbose). 


-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 


José, 

Como assim, não vem mensagem? O arquivo de log não é escrito? o pause é 
inserido dentro de qual arquivo, dentro do arquivo que realiza o backup? 

Obrigado. 



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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 
José, 

Executa um teste, cria arquivo de dump que só faz o backup de uma tabela 
pequena e coloca para logar em um arquivo de log. 
Após isso, terá mais contexto para analizar. 

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] postgresql.conf não encontrado




De: "Neto pr"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Sexta-feira, 3 de novembro de 2017 9:31:54 
Assunto: [pgbr-geral] postgresql.conf não encontrado 

Olá 

Estava tentando instalar o postgresql via este tutorial [1] para utilizar a 
ferramenta para bd Powa. 

Uso S.O. debian 8 Jessie. 

Executei: 
apt-get install postgresql-9.6 postgresql-client-9.6 postgresql-contrib-9.6 
apt-get install postgresql-9.6-powa 

Até ai tudo bem, o SGBD subiu e consigo criar tabelas etc. 

Mas não estou encontrando onde está o arquivo postgresql.conf. 
Tentei pesquisar utilizando locate postgresql.conf, más não encontra, desconfio 
que não foi criado. 
Preciso adicionar algumas bibliotecas no parametro: shared_preload_libraries 

Alguém já instalou o postgresql desta forma, e poderia informar onde pode estar 
o arquivo postgresql.conf, ou outro para configurar o parametro 
shared_preload_libraries ? 

[1] http://powa.readthedocs.io/en/latest/quickstart.html 

[]`s Neto 

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

-- 

Neto, 

antes de utilizar o locate, faça atualização do dicionário de arquivos no 
linux, com comando "updatedb". 
Sobre o postgresql.conf, ele estará dentro do diretório /etc/postgresql/... 
caso não foi modificado na instalação. 

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] PG_DUMP - Tamanho do Arquivo resultantes está errado

De: "José Mello Júnior"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quarta-feira, 1 de novembro de 2017 18:04:41 
Assunto: Re: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Coloquei até um PAUSE dentro do arquivo de lote de execução, mas não vem 
qualquer mensagem. 
Att 


Em 1 de novembro de 2017 14:34, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 





BQ_BEGIN

Não estou descobrindo porque o dump da base de dados está ficando com 1kb ao 
final da execução. O tamanho deveria ser aproximadamente 500Mb, e no tempo em 
que executa vejo o tamanho do arquivo ir crescendo normalmente, mas ao final o 
tamanho fica incompatível. 
Linha pg_dump: 

"C:\Program Files\PostgreSQL\9.3\bin\pg_dump.exe" --host localhost --port 5432 
--username "backup" --role "backup" --format custom --blobs --encoding 
SQL_ASCII --inserts --column-inserts --disable-dollar-quoting --verbose --file 
"C:\BKP\20171031172048000\notas.backup" --schema "notas" "gn" 

O que pode estar acontecendo? 




Você pode mandar o log da execução? Talvez ajude utilizando a opção -v 
(verbose). 


-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

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

BQ_END




-- 
Mello Júnior 
41.3252-3555 

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

-- 


José, 

Como assim, não vem mensagem? O arquivo de log não é escrito? o pause é 
inserido dentro de qual arquivo, dentro do arquivo que realiza o backup? 

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] Ajuda com SELECT

De: "Antonio Cesar"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quinta-feira, 2 de novembro de 2017 9:44:44 
Assunto: [pgbr-geral] Ajuda com SELECT 

Bom dia, 

Estou com esse comando com uma percima peformace. 

OBs Tava funcionando normal de uma hora para outra ficou muito lento. 

"Limit (cost=0.26..117.46 rows=100 width=385)" 
" -> Nested Loop (cost=0.26..36017.81 rows=30730 width=385)" 
" -> Merge Join (cost=0.26..27384.58 rows=30730 width=389)" 
" Merge Cond: (its.codigo = ip.codigo_item)" 
" Join Filter: (its.codigo_unidade = ip.codigo_unidade)" 
" -> Index Scan using pk_item_codigo on item its 
(cost=0.00..8508.14 rows=33680 width=385)" 
" Filter: ((tipo_item <> ALL ('{07,08}'::bpchar[])) 
AND (ativo = 'S'::bpchar))" 
" -> Index Scan using pk_item_preco_codigo on item_preco 
ip (cost=0.00..18258.11 rows=56550 width=8)" 
" Index Cond: ((codigo_empresa = 2) AND 
(codigo_negocio = 1))" 
" Filter: ((ativo)::bpchar = 'S'::bpchar)" 
" -> Index Only Scan using pk_unidade_codigo on unidade un 
(cost=0.00..0.27 rows=1 width=4)" 
" Index Cond: (codigo = ip.codigo_unidade)" 

Servidor: 

mem 32GB 

Linux debian 

Processador 8 Nucle 

Marca DELL 

Conexao simutaneo 18 


___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 
de Banco de Dados 
Departamento Data Center 
daniel.si...@ipm.com.br 
48 3031-7500 

Antonio, 

Utiliza esse site [1] para conseguir analisar performance de query. 

Sobre a query o que mais consome é no índice pk_item_preco_codigo e realizar o 
merge entre os registros. Mas o que seria lento para você? Essa consulta 
movimenta poucos registros, acredito que demora mais de 1 segundo para 
executar, mas caso demore terá que validar se o caminho seguido é bom 
suficiente para seu negócio. 

[1] http://tatiyants.com/pev/#/plans/new 
___
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_DUMP - Tamanho do Arquivo resultantes está errado

2017-11-01 Por tôpico Daniel Luiz da Silva




De: "José Mello Júnior"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quarta-feira, 1 de novembro de 2017 11:25:10 
Assunto: [pgbr-geral] PG_DUMP - Tamanho do Arquivo resultantes está errado 

Não estou descobrindo porque o dump da base de dados está ficando com 1kb ao 
final da execução. O tamanho deveria ser aproximadamente 500Mb, e no tempo em 
que executa vejo o tamanho do arquivo ir crescendo normalmente, mas ao final o 
tamanho fica incompatível. 
Linha pg_dump: 

"C:\Program Files\PostgreSQL\9.3\bin\pg_dump.exe" --host localhost --port 5432 
--username "backup" --role "backup" --format custom --blobs --encoding 
SQL_ASCII --inserts --column-inserts --disable-dollar-quoting --verbose --file 
"C:\BKP\20171031172048000\notas.backup" --schema "notas" "gn" 

O que pode estar acontecendo? 

Muito obrigado 

-- 
Mello Júnior 
41.3252-3555 

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

-- 

José, 
porque não estás colocando para logar esse dump? Cria um arquivo de log para 
conseguir intender o que está acontecendo. 
Basta colocar no final do comando dump esse código: 

>> " C:\BKP\20171031172048000\ bkp.log" 2>&1 
echo "FIM" 
pause 

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] missing chunk number 0 for toast value 382548694 in pg_toast_847386

2017-10-24 Por tôpico Luiz Carlos L. Nogueira Jr.

Por segurança, tira logo um backup com o ambiente parado.

Tenta reindexar a tabela e torce pra ser num índice. Essa é a 1a coisa a
ser feita.

Depois tenta um vacuum full na tabela

MAS NÃO ESQUECER DE TIRAR O BACKUP ANTES!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Delete ou Update em dois registros identicos

2017-10-23 Por tôpico Luiz Carlos L. Nogueira Jr.

Fazer um update com limit 1 não funcionaria?

Em 17 de outubro de 2017 10:17, Edelson Regis de Lima <edre...@gmail.com>
escreveu:

> Obrigado pessoal!
> Obrigado a todos pela ajuda!
>
> Grande abraço!
>
> --
> *Edelson Regis de Lima*
>
> Em 16 de outubro de 2017 15:01, Michel Luiz Milezzi <
> michelmile...@gmail.com> escreveu:
>
>> Edelson, neste caso você deve usar a localização física dos registros
>> (coluna implícita ctid).
>>
>> https://www.postgresql.org/docs/current/static/ddl-system-columns.html
>>
>> Em 16 de outubro de 2017 15:51, Danilo Silva <danilo.dsg.go...@gmail.com>
>> escreveu:
>>
>>>
>>>
>>> Danilo Gomes
>>>
>>> Em 16 de outubro de 2017 15:32, Edelson Regis de Lima <edre...@gmail.com
>>> > escreveu:
>>>
>>>> Olá Flávio.
>>>>
>>>> Mas com esse exemplo você está supondo que na tabela exista o campo
>>>> "id" que seria uma chave única, correto?
>>>> O problema é que nessa tabela que mencionei não sei porque raios não
>>>> existe essa chave única. Tem um campo id, auto incremento, que seria essa
>>>> chave única, mas não sei como o sistema conseguiu inserir dois registros
>>>> identicos, inclusive o valor do id...
>>>> Então eu teria que ver se dá para identificar de outra maneira, pela
>>>> posição física do registro, sei lá...
>>>> Não sei se isso é possível... rs
>>>>
>>>> Você tem duas opções:
>>> a) se a tabela possuir o campo OID (essa coluna normalmente fica
>>> invisível, depende do método de criação da tabela), você pode deletar por
>>> esse registro, exemplo: SELECT OID, col_a,
>>> col_
>>> b FROM tabela, e depois deletar: DELETE FROM tabela WHERE (OID = ?)
>>>
>>> b) se a tabela não for muito grande, você pode adicionar uma nova coluna
>>> com 
>>> 
>>>
>>> o tipo sendo serial: ALTER TABLE tabela ADD COLUMN cod_delete serial.
>>> Com isso você consegue deletar através do código dessa coluna.
>>>
>>> []s
>>> Danilo
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Delete ou Update em dois registros identicos

2017-10-16 Por tôpico Michel Luiz Milezzi

Edelson, neste caso você deve usar a localização física dos registros
(coluna implícita ctid).

https://www.postgresql.org/docs/current/static/ddl-system-columns.html

Em 16 de outubro de 2017 15:51, Danilo Silva 
escreveu:

>
>
> Danilo Gomes
>
> Em 16 de outubro de 2017 15:32, Edelson Regis de Lima 
> escreveu:
>
>> Olá Flávio.
>>
>> Mas com esse exemplo você está supondo que na tabela exista o campo "id"
>> que seria uma chave única, correto?
>> O problema é que nessa tabela que mencionei não sei porque raios não
>> existe essa chave única. Tem um campo id, auto incremento, que seria essa
>> chave única, mas não sei como o sistema conseguiu inserir dois registros
>> identicos, inclusive o valor do id...
>> Então eu teria que ver se dá para identificar de outra maneira, pela
>> posição física do registro, sei lá...
>> Não sei se isso é possível... rs
>>
>> Você tem duas opções:
> a) se a tabela possuir o campo OID (essa coluna normalmente fica
> invisível, depende do método de criação da tabela), você pode deletar por
> esse registro, exemplo: SELECT OID, col_a,
> col_
> b FROM tabela, e depois deletar: DELETE FROM tabela WHERE (OID = ?)
>
> b) se a tabela não for muito grande, você pode adicionar uma nova coluna
> com 
> 
>
> o tipo sendo serial: ALTER TABLE tabela ADD COLUMN cod_delete serial. Com
> isso você consegue deletar através do código dessa coluna.
>
> []s
> Danilo
>
> ___
> 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] Slides - PGBR 2017

2017-10-11 Por tôpico Daniel Luiz da Silva




De: "Fabiano Machado Dias"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Sexta-feira, 22 de setembro de 2017 11:19:14 
Assunto: Re: [pgbr-geral] Slides - PGBR 2017 

Não sabia! Obrigado pelo retorno. 

Abs. 
Fabiano 

Em 22 de setembro de 2017 11:15, Sebastian Webber < sebast...@swebber.me > 
escreveu: 





Em sex, 22 de set de 2017 às 11:12, Fabiano Machado Dias < 
fabi...@wolaksistemas.com.br > escreveu: 

BQ_BEGIN

Queria muito ver a palestra do Emerson Engroff, PG em Memória, infelizmente não 
consegui ir pela manhã no evento. 




Ele acabou não vindo e usamos a sala pra extender outra palestra. 

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

BQ_END



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

Sebastian, 

Foi liberado todos slides do PGBR 2017? Qual endereço de acesso? 

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] RES: RES: converter ascii para utf8

2017-09-27 Por tôpico Daniel Luiz da Silva

De: "Santiago - NSR"
Para: "Comunidade PostgreSQL Brasileira"
Enviadas: Quarta-feira, 27 de setembro de 2017 9:03:59
Assunto: [pgbr-geral] RES: RES: converter ascii para utf8

Bom dia. o banco está em ASCII. Necessito passar para UTF8. Quando uso a opção
-E UTF8 (do pg_dump) da erro...(ao contrario do que escribi).
Fiz uma função usando o "translate", estou migrando tabela a tabela e está
dando certo...

resSTR_ = translate($1,
'áàâãäåaaaÁÂÃÄÅAAAÀéèêëeEEEÉEEÈìíîïìiiiÌÍÎÏÌIIIóôõöoooòÒÓÔÕÖOOOùúûüÙÚÛÜçÇñÑýÝ',

'aAeEEEcCnNyY'

);

Santiago Cuello
NSR Informática
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Bom dia,
Santiago,

Não sei se já foi falado aqui nesse e-mail, mas é possível setar o
client_enconding no momento da transação, caso resolva teu problema. segue link
[1]. Mas acredito que seu problema é porque não está disponibilizado o
encolding dentro do sistema operacional, veja esse link [2], e avalia se
resolve tua situação.
Isso é um assunto bem rico de informação na internet, caso queira pesquisar
algo irá encontrar bastante conteúdo. Lembre-se que isso é um caso que poderá
acontecer para qualquer banco de dados e qualquer linguagem de programação,
então caso não encontre o que deseja em PostgreSQL, altera a busca para outros
bancos/linguagens de programação, que encontrará.

[1]https://www.postgresql.org/docs/current/static/multibyte.html
[2]https://littleoak.wordpress.com/2008/09/23/corrigindo-maldito-encoding-do-postgres-para-poder-usar-banco-de-dados-latin1-ou-outro-e-mudar-o-encoding-do-sistema-operacional-ubuntu-ou-debian/

___
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 e Vacuum Full

2017-09-22 Por tôpico Daniel Luiz da Silva




De: "Fernando Franquini 'capin'"  
Para: "Lista: Comunidade PostgreSQL Brasileira" 
 
Enviadas: Sexta-feira, 22 de setembro de 2017 16:36:46 
Assunto: [pgbr-geral] Vacuum e Vacuum Full 

Boa tarde, 
tenho um ambiente com Postgres 9.3.19. 
Linux Centos 6 Kernel 2.6.32-504.12.2.el6.x86_64 (sei que é velho! eheh) 

Tenho várias tabelas que são removidos e inseridos vários dados durante o dia 
todo, tempo todo. 

Preciso as vezes executar vacuum e vacuum full na mão, vou colocar um print 
para terem ideia dos volumes de dados: 


Os meus parâmetros do Autovacuum estão no padrão: 

O Autovacuum quase não tem executado, logo, os parâmetros não estão atendendo, 
em conversa com o Fabrizio alterei alguns parâmetros direto nas tabelas. 

O problema que não tenho entendido é que mesmo após executar os comandos de 
Vacuum ou Vacuum full nessas tabelas, os valores ainda permanecem inalterados. 

Alguém saberia me dizer mais alguma coisa? 

Grato pela atenção. 
-- 
Capin 
Graduado: Bacharel em Ciências da Computação - UFSC 
Analista de Sistemas e de Banco de Dados / DBA 
48.9924.8212 Vivo - Florianópolis - SC - Brasil 
http://certificacaobd.com.br/ 
http://br.linkedin.com/in/capin 


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

-- 

Fernando, 

Acredito que o Fabrízio já falou sobre isso, mas se não falou é importante 
monitorar essas tabelas que tem mais alterações e configurar o autovacuum mais 
agressivo, ou seja, executar mais vezes durante o dia, mas claro, sempre 
lembrando que essa organização custa para manter tudo "em ordem". Se tua(s) 
tabela(s) está desorganizando com muita frequência tem intervir para que isso 
não aconteça, mas é necessário avaliar essa necessidade. 
Que tabela é essa? Esses percentuais, se for sobre percentuais calculados de 
linhas mortas dentro da tabela, de que forma está executando o calculo? 
Assunmindo esses valores como reais, pode-se considerar baixo 0.65%, MAS 
CUIDADO, depende do ambiente que estás trabalhando. 
Esse valor bom de percentual de linhas mortas, ou percentual de desorganização 
na tabela, só testando as consultas mais executadas e verificar se vale o 
investimento de manter toda ordem. 

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] tutorial e dicas de explain analyze

2017-09-22 Por tôpico Luiz Henrique

Uellinton

A tabela ned_nota_empenho_despesa tem 174.000
A tabela orcamentario_mensal tem 63.000
Ambas com indice


2017-09-22 10:50 GMT-03:00 Uellinton Mendes <uellin...@terra.com.br>:

> Bom Dia Luiz,
>
> Já tentou usar essa ferramenta online?
>
> https://explain.depesz.com/
>
> É muito legal.
>
> Duvida, quantos registros tem mesmo em ned_nota_empenho_despesa e
> orcamentario_mensal?
>
> Essas duas tabelas estão sem indices?
>
> *Uellinton Mendes*
> 11-9-9167-3524 [OI]
>
> Em 22/09/2017 10:39, Luiz Henrique escreveu:
>
> Prezados,
>
> Procuro por links com tutorias aborando o "explain analyze". Como
> interpretar cada linha apresentada por ele. Alguém recomenda algum site ?
>
> Tenho uma consulta aqui com 1,5 minuto de duração e gostaria de tentar
> otimiza-la
> Ao executar o explain analyze não entendi bem onde atuar para melhorar
>
> Segue abaixo o sql e o explain. Toda ajuda será bem-vinda
>
> ### explain analyze
>
> explain analyze select distinct npd.exercicio
>   , npd.unidadegestora
>   , npd.numero
>   , npd.numeronld
>   , nld.numero as nldorigem
>   , nld.numeroned
>   , ned.numero as nedorigem
>   , ned.numeronpf
>   , npf.numero as npforigem
>   , npf.grupo_fin as grupofin
>   , orm.cod_tp_orcamento as tipcre
>   , npd.classiforcamreduz
>   , npd.classiforcamcompl
>   , npd.credor
>   , npd.nomecredor
>   , npd.statusmovbancario
>   , npd.natureza
>   , nld.numeroned as numemp
>   , npd.codigoretencao
>   , npd.dataemissao
>   , npd.dt_etl
>   , npd.servicobancario
>   , npd.bancobeneficiario as banco
>   , npd.agenciabeneficiario as agencia
>   , npd.contabeneficiario as conta
>   , npd.efeito
>   , substring(ned.classiforcamcompl from 24 for 8) as natdespesa
>   , substring(ned.classiforcamcompl from 33 for 2) as fonterec
>   , npd.valor as valor
>   , npd.cpfcnpjcredor
>   , cast(npd.numeronld as integer) as "numliq"
>   , npd.numeronpf
>   , npd.numeronpdordinario
>   , exerciciorestosapagar
> from sefaz_ws.npd_nota_pagamento_despesa npd
> left join sefaz_ws.nld_nota_liquidacao_despesa nld
>  on (npd.exercicio = nld.exercicio
>  and npd.unidadegestora = nld.unidadegestora
>  and npd.numeronld = nld.numero)
> left join sefaz_ws.ned_nota_empenho_despesa ned
>  on (nld.exercicio = ned.exercicio
>  and nld.unidadegestora = ned.unidadegestora
>  and nld.numeroned = ned.numero)
> left join sefaz_ws.npf_nota_programacao_financeira npf
>  on (ned.exercicio = npf.exercicio
>  and ned.unidadegestora = npf.unidadegestora
>  and ned.numeronpf = npf.numero)
> left join sefaz_ws.orcamentario_mensal orm
>  on (npd.exercicio = orm.exercicio and npd.unidadegestora =
> orm.unidadegestora and orm.classif_orcam_reduz = CAST(ned.classiforcamreduz
> AS integer))
> order by npd.exercicio, npd.unidadegestora, npd.numero
>
>  resultado do explain analyze
>
> "Unique  (cost=358689.48..389491.06 rows=352018 width=287) (actual
> time=101865.980..107098.130 rows=352018 loops=1)"
> "  ->  Sort  (cost=358689.48..359569.53 rows=352018 width=287) (actual
> time=101865.979..103271.970 rows=2631834 loops=1)"
> "Sort Key: npd.exercicio, npd.unidadegestora, npd.numero,
> npd.numeronld, nld.numero, nld.numeroned, ned.numero, ned.numeronpf,
> npf.numero, npf.grupo_fin, orm.cod_tp_orcamento, npd.classiforcamreduz,
> npd.classiforcamcompl, npd.credor, npd.nomecredor, npd.statusmovbancario,
> npd.natureza, npd.codigoretencao, npd.dataemissao, npd.dt_etl,
> npd.servicobancario, npd.bancobeneficiario, npd.agenciabeneficiario,
> npd.contabeneficiario, npd.efeito, ("substring"((ned.classiforcamcompl)::text,
> 24, 8)), ("substring"((ned.classiforcamcompl)::text, 33, 2)), npd.valor,
> npd.cpfcnpjcredor, npd.numeronpf, npd.numeronpdordinario,
> nld.exerciciorestosapagar"
> "Sort Method: external merge  Disk: 731704kB"
> "->  Hash Left Join  (cost=104246.16..279334.81 rows=352018
> width=287) (actual time=1322.332..6808.805 rows=2631834 loops=1)"
> "  Hash Cond: ((npd.exercicio = orm.exercicio) AND
> (npd.unidadegestora = orm.unidadegestora) AND 
> ((ned.classiforcamreduz)::integer
> = orm.classif_orcam_reduz))"
> "  ->  Merge Left Join  (cost=100158.37..188918.69 rows=352018
> width=290) (actual time=1295.093..3653.514 rows=352018 loops=1)"
> "Merge Cond: ((npd.unidadegestora =
> nld.unidadegestora) AND (npd.exercicio = nld

[pgbr-geral] tutorial e dicas de explain analyze

2017-09-22 Por tôpico Luiz Henrique

roned on
nld_nota_liquidacao_despesa nld  (cost=0.00..23405.46 rows=198865 width=21)
(actual time=0.008..77.818 rows=198865 loops=1)"
"->  Sort  (cost=54937.55..55372.62
rows=174029 width=70) (actual time=749.864..771.572 rows=200712 loops=1)"
"  Sort Key: ned.unidadegestora,
ned.exercicio, ned.numero"
"  Sort Method: quicksort  Memory:
30617kB"
"  ->  Merge Right Join
(cost=28198.62..39789.22 rows=174029 width=70) (actual
time=363.928..494.100 rows=174029 loops=1)"
"Merge Cond: ((npf.exercicio =
ned.exercicio) AND (npf.unidadegestora = ned.unidadegestora) AND
(npf.numero = ned.numeronpf))"
"->  Index Scan using
npf_nota_programacao_financeira_idx on npf_nota_programacao_financeira npf
(cost=0.00..7688.10 rows=100339 width=15) (actual time=0.008..30.949
rows=100339 loops=1)"
"->  Sort
(cost=28198.62..28633.69 rows=174029 width=63) (actual
time=363.906..384.312 rows=174029 loops=1)"
"  Sort Key: ned.exercicio,
ned.unidadegestora, ned.numeronpf"
"  Sort Method: quicksort
Memory: 30617kB"
"  ->  Seq Scan on
ned_nota_empenho_despesa ned  (cost=0.00..13050.29 rows=174029 width=63)
(actual time=0.003..63.878 rows=174029 loops=1)"
"  ->  Hash  (cost=2991.47..2991.47 rows=62647 width=14)
(actual time=27.200..27.200 rows=62647 loops=1)"
"Buckets: 8192  Batches: 1  Memory Usage: 2937kB"
"->  Seq Scan on orcamentario_mensal orm
(cost=0.00..2991.47 rows=62647 width=14) (actual time=0.006..15.844
rows=62647 loops=1)"
"Total runtime: 107298.538 ms"







-- 
Atenciosamente,

Luiz Henrique
"In Medium Est Virtus!"
"A Virtude está no meio!"
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas p/ recomendação de índices

2017-09-20 Por tôpico Cleiton Luiz Domazak

2017-09-20 12:50 GMT-03:00 Neto pr :

> Olá Pessoal
>
> Estou pesquisando sobre Ferramentas para Recomendação de Índices
> (Index-Advisor) para ser aplicados em consultas SQLs.
> A principio encontrei estes:
>
> - EnterpriseDB - https://www.enterprisedb.com/docs/en/9.5/asguide/EDB_
> Postgres_Advanced_Server_Guide.1.56.html
> - Powa http://dalibo.github.io/powa/
>

Uma ferramenta muito interessante também é o Dexter [1].

1- https://github.com/ankane/dexter

>
> Alguém saberia de outras ferramentas para este propósito. Caso já tenham
> usados estas acima, se puderem informar o que acharam.
>
> Grato
> []'s Neto
>
> ___
> 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] Ajuda parâmetro work_mem

2017-09-06 Por tôpico Daniel Luiz da Silva




De: "Fábio Telles Rodriguez"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quarta-feira, 6 de setembro de 2017 12:34:38 
Assunto: Re: [pgbr-geral] Ajuda parâmetro work_mem 



Em 6 de setembro de 2017 11:19, Neto pr < neto...@gmail.com > escreveu: 


Pessoal 

Já li em alguns foruns como abaixo, que alterar o Shared_Buffer para 
deixar mais memória RAM disponível p/ o SGBD as vezes acaba por 
diminuir o desempenho: 

https://www.postgresql.org/message-id/CACezXZ_w7HbqSxZ=5SJH=kxb4nbdnbpdejttsau6ec1aeo4...@mail.gmail.com
 

Mas e no caso do Work_Mem, responsável por limitar a quantidade de 
memória RAM para o operacões de classificacão e ordenacão para uma 
única operacão, será que teria algum efeito colateral em alterar isso, 
para uma quantidade maior? 

Estou fazendo testes com o benchmark TPCH e quase todas as consultas 
tem group e order by. 
https://www.maxwell.vrac.puc-rio.br/acessoConteudo.php?nrseqoco=42150 
(pagina 37) 

Peguei duas indicacões pelas ferramentas abaixo, no meu caso estou com 
um Servidor dedicado e com poucas conexões sendo utilizadas, no máximo 
10, e vejam o que foi me indicado: 

- pgtune = 104 MB (para 10 conexões no máximo). 
- pgconfig.org = 410 MB (para 10 conexões no máximo) 

Alguma opinião se a alteracão desse parametro, traria algum efeito 
maléfico no desempenho? 
Que valores utilizam x conexões? 

Os outros parametros eu utilizo o padrão, a versão do postgresql é a 
10b3, Proc Xeon 2.8GHz/4-core- 8gb Ram, SO Debian 8. 



O valor do WORK_MEM deve ser o maior possível. Mas o melhor valor pode variar 
um pouco com o seu ambiente. Primeiro eu deixo para logar por um tempo no 
servidor a criação de tabelas temporárias. Depois gero um relatório com o 
pgBadger e avalio a geração de arquivos temporários no pgBadger. 
- Se o volume de tabelas temporárias criadas em disco for muito pequeno, é 
sinal de que não há muita necessidade de aumentar o WORK_MEM. 
- Se apenas algumas sessões estão gerando grandes arquivos temporários, eu 
tento ajustar o WORK_MEM maior só para aquelas sessões ou usuários. 
- Se muitas sessões estão gerando arquivos temporários eu aumento o WORK_MEM 
globalmente. 

Em geral ajusto o MAX_CONNECTIONS x WORK_MEM para algo entre 25% a 50% da RAM 
do servidor. Mas isso é apenas um chute inicial, imaginando que teremos 25% 
para o SHARED_BUFFERS e 25% para as sessões e 50% para o cache do SO. 

-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

Fábio, 

Sei que não é o foco do tópico, mas fiquei com dúvida no cálculo da memória 
para o PostgreSQL, porque existe muitas fôrmulas na internet. Porém, é tudo 
empirico, não visualizei nenhum tópico até hoje que explica porque das 
configurações. 
Eu por exemplo, sempre utilizei essa: Calculo da memória = (shared_buffers + ( 
2 * max_connections * work_mem) + ( autovacuum_max_workers * 
maintenance_work_mem) ) 
Outra dúvida do work_mem, com esse acompanhamento é se seria possível 
acompanhar a quantidade de work_mem utilizada para operações de ordenação, join 
e distinct, nas consultas. Nesse mesmo acompanhamento para tabelas temporárias 
seria possível visualizar isso? 

Obrigado. 

___ 
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] Vacuum e autovacuum

2017-09-04 Por tôpico Luiz Carlos L. Nogueira Jr.

Fabio/Euler,

E o que fazer para evitar que o autovacuum rode durante o expediente?
Não entendo uma coisa. Se eu passo o vacuum manual achava que ele dizia
"olhe não tem linhas a serem recicladas", mas isso não acontece pois o
autovacuum não considera isso
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Integração MSSQL

2017-09-01 Por tôpico Cleiton Luiz Domazak

2017-09-01 13:26 GMT-03:00 Artur Zanini :

> Boa tarde, pessoal.
>
> Preciso integrar o Postgres com MSSQL.
> Existe um passo-a-passo?
> Ou por onde devo começar?
>

Defina melhor o que seria essa integração.

>
>
> =
> Ass.:
> Artur Gnecco Zanini
> Fone.:  51 92232129 <(51)%209223-2129>
> Gtalk: artur.zan...@gmail.com
> =
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-31 Por tôpico Daniel Luiz da Silva




De: "Marcelo Kruger"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quinta-feira, 31 de agosto de 2017 7:42:46 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Bom dia Fabio, 
Creio que tenha me expressado da maneira incorreta. Não faço nenhuma alteração 
para copia de archives uma vez que todo o pg_xlog é transferido para a outra 
maquina via WAL Sender sem que tenha que fazer alterações tanto no 
recovery.conf, quanto no postgres.conf de ambas as maquinas. Criamos um slot e 
definimos o banco como hot standby, o procedimento que por sua vez fará com que 
o a replica receba os arquivos da maquina master, e isso esta ocorrendo 
corretamente e de forma instantanea. 

Entretanto irei seguir as recomendações passadas por você, e irei testar o 
procedimento do Euler. 

Agradeço desde já pela atenção. 

Att, 

Em 31 de agosto de 2017 06:45, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 





Em 30 de agosto de 2017 19:21, Marcelo Kruger < marcelo.kru...@neoway.com.br > 
escreveu: 

BQ_BEGIN

Daniel, 

Devido ao archive estar por padrão no pg_xlog não foi necessario especificar o 
archive_command. 



Você está fazendo confusão! Jamais copie arquivos diretamente para dentro ou 
para fora do pg_xlog. Deixe que o PostgreSQL gerencie esta área para você. 

Monte o Standby de acordo com o procedimento normal. Se estiver na dúvida, siga 
o procedimento do artigo do Euler Taveira em: 
http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html 


-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

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

BQ_END



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


Marcelo, 
Esse artigo explica bem como configurar diferentes cenários de replicação. Mas 
no seu caso, perceba que a princípio, não existe configuração para recebimento 
do slot de replicação. Então algum problema com configuração de hardware ou 
rede, pode estar acontecendo. 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Vacuum e autovacuum

2017-08-30 Por tôpico Luiz Carlos L. Nogueira Jr.

Pessoal,

Estava notando uma coisa em relação ao vacuum e autovacuum.
Como estava ocorrendo muito autovacuum no horário de expediente numa certa
tabela, coloquei pra ser feito um vacuum todo dia fora do expediente.
Hoje o autovacuum apareceu de novo e fui olhar as estatísticas da tabela e
tinha:
last autovacuum: 23/08/2017 ...
last vacuum: 29/08/2017 ...

Eu imaginei que dando o vacuum ele "zeraria" as estatísticas pros
autovacuums futuros, mas isso não está acontecendo. Esse comportamento é
"normal"? Se sim, por que?

"PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-4), 64-bit"

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

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication




De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 16:23:54 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, 
O arquivo im_the_master é apenas uma trigger para transitar o servidor do 
stand-by para a produção. É um arquivo vazio, nosso processo cria este arquivo 
quando identifica que o servidor principal não esta respondendo. 

Quanto ao shared_buffer haviamos lido esta questão do tamanho. Chegamos a 
reduzir o shared, mas o tempo de processamento do archive ficou na mesma media 
de tempo. 

Att, 

Marcelo, 
Como está o archive_command no slave? 

Em 30 de agosto de 2017 16:16, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 






De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 16:03:21 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, quanto a questão do checkpoint_completion_target não havia me atentato. 
E desta forma justificaria o tempo de descarga dos dados em disco. O 
shared_buffer é elevado em nosso caso pois nosso processamento de dados exige 
tal configuração de memoria. 
Daniel, o arquivo de recovery.conf está da seguinte forma 

standby_mode = 'on' 
primary_slot_name = 'bdreplica01' 
primary_conninfo = 'host=bdreplica00 port=5433 user=replication' 
trigger_file = '/var/lib/pgsql/9.6/data/im_the_master' 

Att, 

Marcelo, 

Normalmente não se utiliza o shared_buffer maior que 8GB, justamente porque tem 
esses malefícios com WAL e recovery caso necessário. Se quiser pesquisar dentro 
do arquivario do forum PostgreSQL Brasil, existe vários tópicos sobre as 
desvantagens de ser maior que 8GB. É interessante acompanhar o pg_buffercache 
do seu cluster, para saber se os arquivos dentro do buffer fica muito tempo, 
com isso, conseguirá comparar se o tamanho do shared_buffer está suficiente ou 
não. 
O que existe dentro do comando im_the_master ? 

Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 

BQ_BEGIN




De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:55:07 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, boa tarde. 
Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que tenho 
350GB de archives no slave que não foram aplicados ainda. Ou seja, o processo 
de WAL Sender envia o arquivo, mas o Slave leva muito tempo para aplicar na 
base de dados. 

Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso será 
o tempo aproximado para processar o arquivo, o tempo de envio deverá ser curto. 

Apos finalizar o archive no master o envio para o slave e instantaneo. Contudo 
notamos que para gerar um arquivo de 16MB no pg_xlog do master está levando 
mais de 10 minutos. E temos operação massiva de inserção e alteração, que não 
justificaria a demora para finalizar este archive. 

Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da base, 
inclusive, esse cluster está configurado com uma valor bem alto de 
shared_buffer, então para ler essa memória e descarregar poderá levar mais 
tempo que previsto. Ler esse link [1] 
O seu checkpoint_timeout está em 10 minutos, porém o 
checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor 
default, como está comentado, e valor no comentário é 0.9, significa que será 
feito uma descarga da memória para o disco de arquivos WAL a cada +-5 minutos 
(10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( 10 minutos * 
0.9), se configurado dessa forma. É importante intender como funciona esse 
processo. 

Mas existe algum problema na slave ainda. Como está configurado seu 
"recovery.conf"? Esse arquivo deveria ler os arquivos que chega 
instantaneamente. 

[1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html 

Att, 



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 

BQ_BEGIN




De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 

BQ_BEGIN


BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication




De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 16:03:21 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, quanto a questão do checkpoint_completion_target não havia me atentato. 
E desta forma justificaria o tempo de descarga dos dados em disco. O 
shared_buffer é elevado em nosso caso pois nosso processamento de dados exige 
tal configuração de memoria. 
Daniel, o arquivo de recovery.conf está da seguinte forma 

standby_mode = 'on' 
primary_slot_name = 'bdreplica01' 
primary_conninfo = 'host=bdreplica00 port=5433 user=replication' 
trigger_file = '/var/lib/pgsql/9.6/data/im_the_master' 

Att, 

Marcelo, 

Normalmente não se utiliza o shared_buffer maior que 8GB, justamente porque tem 
esses malefícios com WAL e recovery caso necessário. Se quiser pesquisar dentro 
do arquivario do forum PostgreSQL Brasil, existe vários tópicos sobre as 
desvantagens de ser maior que 8GB. É interessante acompanhar o pg_buffercache 
do seu cluster, para saber se os arquivos dentro do buffer fica muito tempo, 
com isso, conseguirá comparar se o tamanho do shared_buffer está suficiente ou 
não. 
O que existe dentro do comando im_the_master ? 

Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 






De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:55:07 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, boa tarde. 
Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que tenho 
350GB de archives no slave que não foram aplicados ainda. Ou seja, o processo 
de WAL Sender envia o arquivo, mas o Slave leva muito tempo para aplicar na 
base de dados. 

Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso será 
o tempo aproximado para processar o arquivo, o tempo de envio deverá ser curto. 

Apos finalizar o archive no master o envio para o slave e instantaneo. Contudo 
notamos que para gerar um arquivo de 16MB no pg_xlog do master está levando 
mais de 10 minutos. E temos operação massiva de inserção e alteração, que não 
justificaria a demora para finalizar este archive. 

Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da base, 
inclusive, esse cluster está configurado com uma valor bem alto de 
shared_buffer, então para ler essa memória e descarregar poderá levar mais 
tempo que previsto. Ler esse link [1] 
O seu checkpoint_timeout está em 10 minutos, porém o 
checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor 
default, como está comentado, e valor no comentário é 0.9, significa que será 
feito uma descarga da memória para o disco de arquivos WAL a cada +-5 minutos 
(10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( 10 minutos * 
0.9), se configurado dessa forma. É importante intender como funciona esse 
processo. 

Mas existe algum problema na slave ainda. Como está configurado seu 
"recovery.conf"? Esse arquivo deveria ler os arquivos que chega 
instantaneamente. 

[1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html 

Att, 



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 

BQ_BEGIN




De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 

BQ_BEGIN


BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 




Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se 
sim, as consultas são demoradas? 
-- 


Atenciosamente. 

Lucas Viecelli 


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

BQ_END


Marcelo, 

Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ no 
server master agora, e acompanha quanto tempo esse arquivo demorar para chegar 
no slave.

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication




De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:55:07 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, boa tarde. 
Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que tenho 
350GB de archives no slave que não foram aplicados ainda. Ou seja, o processo 
de WAL Sender envia o arquivo, mas o Slave leva muito tempo para aplicar na 
base de dados. 

Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso será 
o tempo aproximado para processar o arquivo, o tempo de envio deverá ser curto. 

Apos finalizar o archive no master o envio para o slave e instantaneo. Contudo 
notamos que para gerar um arquivo de 16MB no pg_xlog do master está levando 
mais de 10 minutos. E temos operação massiva de inserção e alteração, que não 
justificaria a demora para finalizar este archive. 

Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da base, 
inclusive, esse cluster está configurado com uma valor bem alto de 
shared_buffer, então para ler essa memória e descarregar poderá levar mais 
tempo que previsto. Ler esse link [1] 
O seu checkpoint_timeout está em 10 minutos, porém o 
checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor 
default, como está comentado, e valor no comentário é 0.9, significa que será 
feito uma descarga da memória para o disco de arquivos WAL a cada +-5 minutos 
(10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( 10 minutos * 
0.9), se configurado dessa forma. É importante intender como funciona esse 
processo. 

Mas existe algum problema na slave ainda. Como está configurado seu 
"recovery.conf"? Esse arquivo deveria ler os arquivos que chega 
instantaneamente. 

[1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html 

Att, 



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 






De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 

BQ_BEGIN


BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 




Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se 
sim, as consultas são demoradas? 
-- 


Atenciosamente. 

Lucas Viecelli 


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

BQ_END


Marcelo, 

Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ no 
server master agora, e acompanha quanto tempo esse arquivo demorar para chegar 
no slave. Além disso, faz uma consulta em alguma tabela que está no servidor 
master, recupera algumas linhas, e verifica quanto tempo +- demora para chegar 
essa informação no slave. 

Obrigado. 
___ 
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 

BQ_END



___ 
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] Lentidão na aplicação do Archive - Stream Replication




De: "Marcelo Kruger"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 




BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 




Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se 
sim, as consultas são demoradas? 
-- 


Atenciosamente. 

Lucas Viecelli 


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

BQ_END


Marcelo, 

Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ no 
server master agora, e acompanha quanto tempo esse arquivo demorar para chegar 
no slave. Além disso, faz uma consulta em alguma tabela que está no servidor 
master, recupera algumas linhas, e verifica quanto tempo +- demora para chegar 
essa informação no slave. 

Obrigado. 
___ 
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] Lentidão na aplicação do Archive - Stream Replication



De: "Marcelo Kruger"  
Para: pgbr-geral@listas.postgresql.org.br 
Enviadas: Quarta-feira, 30 de agosto de 2017 12:09:56 
Assunto: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Boa tarde a todos, 
Possuimos uma arquitetura na nuvem da Azure com duas maquinas de banco com a 
versão 9.6 do Postgres. Esta estrutura trabalha com uma maquina sendo o banco 
principal, e a outra sendo a replica deste banco. A replicação é de forma 
assincrona e via Stream Replication, utilizando um Slot para replicação. 

Ambas as maquinas possuem os mesmos recursos de hardware, e as mesmas 
otimizações em SO 


Disco: 17TB para database, sendo 9TB consumido. Disco é um RAID 0 de 17SSDs de 
1TB 
144 GB de memoria 
20 nucleos de processamento 

A maquina principal tem otima performance, enviando os archives do pg_xlog em 
uma rede de banda maxima de 1,5GB/s. Identificamos que não existe problema e 
lentidão no envio e recebimento dos arquivos na replica. Entretando quando o 
postgres replicado inicia o processo de recovery destes archives demora um 
tempo muito elevado, estando em media 15 segundos para processar um archive. 
Isso esta causando uma diferença de dados entre os bancos muito elevada, 
fazendo desta forma que a replicação nunca finalize o processamento dos 
archives. 

Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 

Segue abaixo configuração do postgresql.conf da replica. 

listen_addresses = '*' 
port = 5433 
max_connections = 2000 
superuser_reserved_connections = 3 
shared_buffers = 35257MB 
work_mem = 18051kB 
maintenance_work_mem = 8GB 
#autovacuum_work_mem = 4GB 
max_stack_depth = 5MB 
dynamic_shared_memory_type = posix 
vacuum_cost_delay = 20 
vacuum_cost_limit = 200 
bgwriter_delay = 10ms 
bgwriter_lru_maxpages = 700 
bgwriter_lru_multiplier = 2.0 
fsync = off 
synchronous_commit = off 
full_page_writes = off 
wal_buffers = 16MB 
wal_writer_delay = 1ms 
checkpoint_timeout = 10min 
max_wal_size = 8GB 
min_wal_size = 4GB 
#checkpoint_completion_target = 0.9 
effective_cache_size = 105772MB 
default_statistics_target = 500 
log_destination = 'csvlog' 
logging_collector = off 
log_directory = 'pg_log' 
log_filename = 'postgresql-%w.log' 
log_file_mode = 0640 
log_truncate_on_rotation = on 
log_rotation_age = 1d 
log_rotation_size = 600MB 
log_min_duration_statement = 0 
log_checkpoints = on 
log_connections = off 
log_disconnections = off 
log_duration = on 
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h' 
log_lock_waits = on 
log_timezone = 'Brazil/East' 
autovacuum = on 
log_autovacuum_min_duration = -1 
autovacuum_max_workers = 8 
autovacuum_naptime = 30s 
autovacuum_vacuum_threshold = 20 
autovacuum_analyze_threshold = 20 
autovacuum_vacuum_scale_factor = 0.2 
autovacuum_analyze_scale_factor = 0.1 
autovacuum_vacuum_cost_delay = -1 
datestyle = 'iso, mdy' 
timezone = 'Brazil/East' 
lc_messages = 'en_US.UTF-8' 
lc_monetary = 'en_US.UTF-8' 
lc_numeric = 'en_US.UTF-8' 
lc_time = 'en_US.UTF-8' 
default_text_search_config = 'pg_catalog.english' 
max_locks_per_transaction = 256 
pgpool.pg_ctl = '/usr/pgsql-9.6/bin/pg_ctl' 
huge_pages=on 
hot_standby = on 
hot_standby_feedback = off 
wal_receiver_timeout = 0 


Att, 

Marcelo, 

Acho que primeiramente teria que intender o local do problema. O arquivo WAL 
quando é replicado do servidor master para o servidor slave, demora quanto 
tempo para chegar no servidor slave? Nesse modo, nunca irá termina o archive, 
ele sempre estará aguardando o arquivo WAL, caso queira observar no log do 
postgres slave ele solta a mensagem aguardando o arquivo "XYZ", até receber 
esse arquivo. Como foi calculado esse atraso em 1.6 dias? Existe um outro 
problema que dependedo do volume de gravação que recebe o servidor master, caso 
o volume seja muito alto, ele seguirá o caminho comum até chegar no servidor 
slave, levará um tempo. O que executa no parâmetro archive_command ? Como 
funciona a movimentação da pasta pg_xlog para pasta archive? Como está o 
parâmetro max_wal_senders ? 

Obrigado. 

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

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

[pgbr-geral] [pgbouncer] configuração auth_query

2017-08-23 Por tôpico Daniel Luiz da Silva

Pessoal, 

Estou configurando pgbouncer 1.7.2 com PostgreSQL 9.5, e necessito realizar 
configuração de autenticação direto pelo banco de dados sem passar pelo arquivo 
de usuários e senhas, que é aconselhado na documentação do pgbouncer. Na 
própria documentação, existe uma variável auth_query, alguém utiliza essa 
variável para realizar esse tipo de autenticação? 
Outra dúvida, existe a possibilidade de deixar configurado para acessar todas 
bases disponível, e não configurar cada uma dentro do arquivo pgbouncer.ini ? 

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] Chave estrangeira x índice

2017-08-20 Por tôpico Cleiton Luiz Domazak

2017-08-19 18:24 GMT-03:00 Neto pr :

> Ola pessoal
>
> Sou novo na utilização de PostgreSQL, e tenho a seguinte duvida.
>
> Segundo alguns autores, ao se criar uma chave primaria, na verdade o
> SGBD cria um índice primário/único no caso de chave primaria. Mas e no
> caso da chave estrangeira, o SGBD indexa a coluna Fk também?
>

Ele faz a criação de index apenas para PK realmente, e uma coisa que você
precisa se preocupar, além de indexar a  FK, é que o tipo de dados da PK e
da FK sejam os mesmos, senão o index não será utilizado para casos em que o
banco precisa checar os valores das chaves. Já tive grandes problemas com
isso, e é uma coisa que muitas vezes é negligenciada e dificil de
identificar.

>
> Pergunto isso pois criei a seguinte chave estrangeira em um banco de
> testes (do benchmark TPCH):
>
> ALTER TABLE ORDERS ADD FOREIGN KEY (O_CUSTKEY) REFERENCES
> CUSTOMER(C_CUSTKEY);
>
> Apos tentei criar um índice secundário btree na tabela ORDERS desta forma:
> CREATE INDEX indice_custkey_customer on ORDERS (O_CUSTKEY);
>
> Achei que o PostgreSQL  Não iria permitir isso, pois pensei que a
> coluna O_CUSTKEY já estava indexada (pela chave estrangeira), mas o
> PostgreSQL aceitou o índice secundário.
>
> Alguém saberia explicar SE ao criar uma chave estrangeira, é criado ou
> não um índice.
> Outro dia estava vendo um plano de execução, e no plano tinha o uso de
> uma chave estrangeira para recuperar registros, por isso também a
> dúvida.
>
> []`s Neto
>   style="border-top: 1px solid #D3D4DE;">
> 
>href="https://www.avast.com/sig-email?utm_medium=email;
> utm_source=link_campaign=sig-email_content=webmail"
> target="_blank"> src="https://ipmcdn.avast.com/images/icons/icon-envelope-
> tick-round-orange-animated-no-repeat-v1.gif"
> alt="" width="46" height="29" style="width: 46px; height: 29px;"
> />
> Livre de vírus.  href="https://www.avast.com/sig-email?utm_medium=email;
> utm_source=link_campaign=sig-email_content=webmail"
> target="_blank" style="color: #4453ea;">www.avast.com.
> 
> 
> 
>  height="1">
> ___
> 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] Remover drop database/table

2017-08-17 Por tôpico Daniel Luiz da Silva




De: "Tiago Brasil"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quinta-feira, 17 de agosto de 2017 14:56:54 
Assunto: Re: [pgbr-geral] Remover drop database/table 

Fabrizio, otima sugestao 

Irei testar em breve. 

Em 17 de agosto de 2017 14:47, Fabrízio de Royes Mello < 
fabri...@timbira.com.br > escreveu: 




Em 17 de agosto de 2017 14:21, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 
> 
> Em 17 de agosto de 2017 14:18, Tiago Brasil < neotbra...@gmail.com > 
> escreveu: 
>> 
>> Não, é o inverso! 
>> 
>> Os dev vao poder criar objetos e esquemas, mas NÃO poderão dropar nada. 
> 
> 
> Aí você complica. Por padrão, quem cria um objeto é dono dele. E todo dono 
> retem o poder de destruir o que criou. É um princípio básico que todo SGDB 
> usa. Você tem duas alternativas: 
> 
> 1) Delegar outra pessoa para criar os objetos. 
> 2) Alterar o dono dos objetos depois que eles foram criados. 
> 

3) utilizar Event Triggers [1] para "barrar" esse DROP . 

Att, 

[1] https://www.postgresql.org/docs/current/static/event-triggers.html 

-- 
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ 
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento 




Outra sugestão que poderia ser incluso, com tudo que já foi citado, é incluir 
um script no cron/eventos do windows, que verifica os objetos que não está como 
owner o usuário "dba", por exemplo, e alterar o proprietário desses objetos. 
Mas teria que verificar se é aplicável para essa situação. 

BQ_BEGIN

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

BQ_END




-- 
-- Tiago Menezes Brasil -- 
Centro Universitário do Estado do Pará ( CESUPA ) 
Bacharel em Ciências da Computação ( BCC ) 
-- Belém - PA - Brasil -- 


___ 
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] Remover drop database/table

2017-08-17 Por tôpico Cleiton Luiz Domazak

2017-08-17 14:21 GMT-03:00 Fábio Telles Rodriguez :

>
>
> Em 17 de agosto de 2017 14:18, Tiago Brasil 
> escreveu:
>
>> Não, é o inverso!
>>
>> Os dev vao poder criar objetos e esquemas, mas NÃO poderão dropar nada.
>>
>
> Aí você complica. Por padrão, quem cria um objeto é dono dele. E todo dono
> retem o poder de destruir o que criou. É um princípio básico que todo SGDB
> usa. Você tem duas alternativas:
>
> 1) Delegar outra pessoa para criar os objetos.
> 2) Alterar o dono dos objetos depois que eles foram criados.
>

Complementando o que todos já comentaram.

Nesse caso acredito que a melhor prática é você utilizar alguma ferramenta
para realizar essas alterações de banco. Como Hibernate, Liquidbase e
FlywayDB.

Ou ainda desenvolver alguma ferramenta interna para "equalização" de base.
Muitas empresas onde trabalhei acabaram desenvolvendo suas próprias
ferramentas, cada uma por uma necessidade expecífica, mas todas com o mesmo
objetivo claro, permitir que o desenvolvedor gere a alteração de banco, e
ela seja efetivada em todas as bases necessárias, sem necessariamente dar
privilégios a vários usuários. Vai por mim, você não quer ter pessoas
mexendo no banco de dados sem supervisão querendo apenas "resolver o meu
problema", mais cedo ou mais tarde, você terá que testar suas habilidades
em executar um bom DRP, que espero que você já tenha.

>
>>
>>
>> Em 17 de agosto de 2017 14:11, Ilton Junior 
>> escreveu:
>>
>>> Pelo que entendi você quer que os devs possam dropar objetos!
>>>
>>> Se for faça isso:
>>>
>>> alter role  superuser;
>>>
>>> Caso queira fazer isso pra todos os users use o seguinte comando:
>>>
>>> select 'alter role ' || usename || ' superuser;'
>>> from pg_user;
>>>
>>>
>>>
>>>
>>> *Ilton Júnior*
>>> Redes de Computadores | LPIC Sênior *| DBA Pleno*
>>> Cel.: +55 85 9915-5540
>>> E-mail: iltonjunio...@gmail.com
>>>
>>> Em 17 de agosto de 2017 13:59, Tiago Brasil 
>>> escreveu:
>>>
 Pessoal, boa tarde.

 Tenho uma database criada no meu servidor, todos os privilégios para os
 desenvolvedores, com exceção o drop table/database.

 Lendo algumas coisas na documentação, vi que somente o owner/superuser
 pode dropar objetos e o bd. No caso, teria algum meio de alcançar esse
 objetivo? Ou é uma limitação do postgres?

 Entendo que apenas os dbas deveriam ter o privilegios de criar e dropar
 objetos, porém aonde trabalho isso seria uma exceção.

 Agradeço qualquer contribuição!

 --
 --*Tiago Menezes Brasil*--
 *Centro Universitário do Estado do Pará* (*CESUPA*)
 *Bacharel em Ciências da Computação* (*BCC*)
 --* Belém - PA - Brasil* --


 ___
 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
>>>
>>
>>
>>
>> --
>> --*Tiago Menezes Brasil*--
>> *Centro Universitário do Estado do Pará* (*CESUPA*)
>> *Bacharel em Ciências da Computação* (*BCC*)
>> --* Belém - PA - Brasil* --
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> Atenciosamente,
> Fábio Telles Rodriguez
> blog: http:// s
> avepoint.blog.br
> e-mail / gtalk / MSN: fabio.tel...@gmail.com
> Skype: fabio_telles
>
> Timbira - A empresa brasileira de Postgres
> http://www.timbira.com.br
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] DBF ==> Postgresql (dbf to postgresql)

2017-08-06 Por tôpico Jorge Luiz

Embora um pouco tardia, aqui vai a minha sugistão:
Use o FME da Safe. Acho que ele converte qualquer coisa para qualquer
coisa, além de outros recursos.
Vale a pena dar uma pesquisada.


Em 3 de agosto de 2017 09:55, Alexsandro Haag <alexsandro.h...@gmail.com>
escreveu:

> Concordo com o Marcio, o PDI para estes casos eh muito pratico.
>
> Em 19/07/2017 21:18, Marcio Junior Vieira escreveu:
>
> 1) Importar bruto para tabela com o nome dos arquivos DBF;
>
>
> De forma simplista usaria estes dois componentes:
>
> Att.
> Alex
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



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

Re: [pgbr-geral] Transferir Banco Postgres para outra máquina

2017-06-24 Por tôpico Luiz Henrique

Tiago,

Desejo transferir de forma definitiva.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Livre
de vírus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Em 23 de junho de 2017 14:33, Tiago José Adami <adam...@gmail.com> escreveu:

> Em 23 de junho de 2017 13:56, Luiz Henrique
> <luiz.henriqu...@gmail.com> escreveu:
> > Mestres!
> >
> > Gostaria de dicas/sugestões de como transferir Banco Postgres para outra
> > máquina.
> > Segue detalhes
> >
> > Ambiente Linux CentOS 6
> > Postgres 9.1
> > Somente 1 Database, tamanho 415 GB
> > Peculiaridade : 95% desse tamanho são binários de arquivos anexados ao
> banco
> > Atualmente o pg_dump leva 22h para terminar
> >
> > Eu preciso transferir esse banco (no menor tempo possível) para outro
> > equipamento similar.
> >
> > Favor sugerir dicas da melhor forma que os senhores indicam
> >
> > 1 - pg_dumpall - pg_restore ?
> > 2 - recursos de replicação ?
> > 3 - rsync ?
> > 4 - outros métodos ???
> >
>
> Você quer transferir o banco de dados permanentemente uma única vez ou
> manter uma cópia atualizada em outro local/servidor?
>
> Tiago J. Adami
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,

Luiz Henrique
"In Medium Est Virtus!"
"A Virtude está no meio!"
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Transferir Banco Postgres para outra máquina

2017-06-23 Por tôpico Luiz Henrique

Mestres!

Gostaria de dicas/sugestões de como transferir Banco Postgres para outra
máquina.
Segue detalhes

Ambiente Linux CentOS 6
Postgres 9.1
Somente 1 Database, tamanho 415 GB
Peculiaridade : 95% desse tamanho são binários de arquivos anexados ao banco
Atualmente o pg_dump leva 22h para terminar

Eu preciso transferir esse banco (no menor tempo possível) para outro
equipamento similar.

Favor sugerir dicas da melhor forma que os senhores indicam

1 - pg_dumpall - pg_restore ?
2 - recursos de replicação ?
3 - rsync ?
4 - outros métodos ???

Fico muito grato pela ajuda! Obrigado



-- 
Atenciosamente,

Luiz Henrique
"In Medium Est Virtus!"
"A Virtude está no meio!"
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-17 Por tôpico Cleiton Luiz Domazak

2017-05-16 22:23 GMT-03:00 Franklin Anderson de Oliveira Souza <
frankli...@gmail.com>:



> Eh um sistema legado nao tem como mexer, o servidor fica com uma media de
> 160 conexoes abertas em sua maioria idle. acho que por enquanto isso nao e
> um problema serio !
>
> Quanto as minha duvida achei varias referencias no historico desde grupo,
> eu devia ter pesquisado antes de enviar este email  !!! Ja me ajudou ehehehe
>
> Em 16 de maio de 2017 21:20, Francisco Porfirio <
> francisco.porfi...@gmail.com> escreveu:
>
>>
>> Em ter, 16 de mai de 2017 às 21:38, Franklin Anderson de Oliveira Souza <
>> frankli...@gmail.com> escreveu:
>>
>>> fui incrementando ao longo dos meses, com esse valor os arquivos
>>> temporario ($PGDTA/base/pgsql_tmp/) diminuiram bastante !
>>>
>> Considere revisar suas querys no lugar de incrementar desta forma o
>> work_mem.
>>
>> Escrita de tempfile em grande quantidade não é algo muito interessante, e
>> se usar demais a work_mem você ocupa toda a memória só com ela.
>>
>> Masss... Se ainda assim você precisar disso tudo, imagino que precisará
>> rever a memória do teu Servidor,  e os parâmetros de memória do Postgres/SO
>>
>> Reforço que eu me concentraria em verificar como  poderia baixar a
>> work_mem
>>
>>>
>>> Em 16 de maio de 2017 20:17, Francisco Porfirio <
>>> francisco.porfi...@gmail.com> escreveu:
>>>

 Em ter, 16 de mai de 2017 às 17:50, Franklin Anderson de Oliveira Souza
  escreveu:

> Ola caros amigos, desculpe a falta de acentuacao !!
>
> Tenho um servidor postgresql que com uma frequencia quase que diaria o
> mesmo altera para o estado de recovery, observando o log do postgresql
> encontrei o seguinte trecho:
>
> -
> LOG:  server process (PID 2529) was terminated by signal 9: Killed
> DETAIL:  Failed process was running: select..
> LOG:  terminating any other active server processes
> WARNING:  terminating connection because of crash of another server
> process
> DETAIL:  The postmaster has commanded this server process to roll back
> the current transaction and exit, because another server process exited
> abnormally and possibly corrupted shared memory.
> HINT:  In a moment you should be able to reconnect to the database and
> repeat your command.
> -
>
> Em seguida observando o log do CentOS encontrei o seguinte:
>
> -
> kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
> oom_adj=0, oom_score_adj=0
> kernel: postmaster cpuset=/ mems_allowed=0
> kernel: Pid: 51831, comm: postmaster Not tainted
> 2.6.32-504.8.1.el6.x86_64 #1
> kernel: Call Trace:
> kernel: [] ? cpuset_print_task_mems_allowed
> +0x91/0xb0
> kernel: [] ? dump_header+0x90/0x1b0
> kernel: [] ? security_real_capable_noaudit+0x3c/0x70
> kernel: [] ? oom_kill_process+0x82/0x2a0
> kernel: [] ? select_bad_process+0xe1/0x120
> kernel: [] ? out_of_memory+0x220/0x3c0
> kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
> kernel: [] ? alloc_pages_vma+0x9a/0x150
> kernel: [] ? handle_pte_fault+0x73d/0xb00
> kernel: [] ? alloc_pages_current+0xaa/0x110
> kernel: [] ? autoremove_wake_function+0x0/0x40
> kernel: [] ? handle_mm_fault+0x22a/0x300
> kernel: [] ? __do_page_fault+0x138/0x480
> kernel: [] ? sys_recvfrom+0xee/0x180
> kernel: [] ? mutex_lock+0x1e/0x50
> kernel: [] ? generic_file_llseek_size+0x8c/0xd0
> kernel: [] ? do_page_fault+0x3e/0xa0
> kernel: [] ? page_fault+0x25/0x30
> -
>
> Pesquisando encontrei na documentacao uma referencia a esse
> problema[1] que mostra claramente que a funcao do kernel esta matando o
> postmaster[2] deixando-o em recovery.
>
> O que eu fiz em um primeiro momento foi incrementar a memoria e depois
> em um horario mais apropriado efetuarei as alteracoes sugeridas na
> documentacao(vm.overcommit_memory, vm.overcommit_ratio, shmmax).
>
> Perguntas:
>
> 1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
> passaram por isso e que decisoes tomaram?
> 2- Estou com dificuldade de mensurar o consumo de memoria do
> postgresql, qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas
> hoje disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo
> que 1/3 equivale no htop com a cor verde e 60% com a cor amarela[3], isso
> significa que esta usando toda a memoria ?!
>

Use o pg_activity para isso.

>
> Dados adicionais:
> Centos 6.6
> Postgresql 9.3.6
> kernel 2.6.32
>
> effective_cache_size = 6GB
> shared_buffers = 6GB
> work_mem = 576MB
>
 Esse valor é muito elevado, assim como o amigo já disse, é melhor vc
revisar as queries do que utilizar esse parâmetro tão alto. Caso a sua
query executa mais de 1 operação de ordenação e coisas

Re: [pgbr-geral] Database is in recovery mode

2017-04-24 Por tôpico Daniel Luiz da Silva

Bom dia, 
Fabrízio, 

Acho esse assunto muito interessante, se houvesse um treinamento na Timbira 
sobre essa relação do Postgres com memória linux internamente, ou seja, 
calcular no momento como está o buffer cache, shared memory e média de 
overcommit, explorando melhor o arquivo vminfo do linux, eu aderia. 
Obrigado por responder esses tipos de tópicos sempre me ajuda bastante. 

Abraço. 


De: "Fabrízio de Royes Mello"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quinta-feira, 20 de abril de 2017 18:10:08 
Assunto: Re: [pgbr-geral] Database is in recovery mode 


Em 20 de abril de 2017 17:55, Tiago José Adami < adam...@gmail.com > escreveu: 
> 
> > 
> > Nem preciso te dizer que deves atualizar pra 9.4.11... 
> 
> Sabia que a primeira coisa que me diriam seria para atualizar ;) 
> 
> E concordo plenamente, mas a instalação é do repositório oficial da 
> Amazon que está desatualizado. Por enquanto uma GMUD para incluir 
> outro repo ainda não foi discutida. 
> 

Faz parte... 


> >> (...) 
> >> WARNING,57P02,"terminating connection because of crash of another 
> >> server process","The postmaster has commanded this server process to 
> >> roll back the current transaction and exit, because another server 
> >> process exited abnormally and possibly corrupted shared memory.","In a 
> >> moment you should be able to reconnect to the database and repeat your 
> >> command." 
> >> (...) 
> > 
> > Só tem essa informação no LOG?? Essa informação que vc pegou não é a causa 
> > e 
> > sim o efeito... vasculhe seu log por mais informações. 
> 
> Estou vasculhando pela 3a vez os logs, mas não há nenhuma informação 
> adicional. Estas mensagens ocorre logo após a execução de um SQL 
> SELECT qualquer. 
> 

Isso é sintoma mesmo de OOMKiller como o colega Felipe mencionou anteriormente. 


> > 
> > Eu arrisco que vc pode estar passando por algum "overcommit_memory" ou 
> > coisa 
> > parecida. Esse linux tem swap e como está o overcommit_memory? 
> 
> O OOM e overcommit estão com os valores padrão 
> 
> vm.oom_dump_tasks = 1 
> vm.oom_kill_allocating_task = 0 
> vm.overcommit_kbytes = 0 
> vm.overcommit_memory = 0 
> vm.overcommit_ratio = 50 
> 

Bingo... 


> O servidor não tem Swap. 
> 

Vejo que não é esse seu problema, mas não custaria nada ter uma área de swap 
para alguma emergência. 


> Estava quase enviando o e-mail quando fui checar novamente o 
> /var/log/messages. Agradeço também ao colega Felipe Pereira (obrigado 
> pelas dicas), desta vez encontrei a causa mortis: 
> 
> Apr 20 18:00:47 ip-172-16-4-27 kernel: [238117.075735] Killed process 
> 2485 (postmaster) total-vm:2124064kB, anon-rss:272232kB, file-rss:4kB, 
> shmem-rss:1588240kB 
> 

Bingo... 


> A questão é: mesmo tendo uma quantidade de memória livre que fica 
> sempre entre 3 e 4 GB (livre, o resto é cache + usada), como isso pode 
> estar acontecendo? 
> 

Isso é por conta do "overcommit_ratio = 50" que indica que foi solicitado 
alocar mais memória que o "total de swap + 50% da RAM" [1] ... como vc nao tem 
swap entao ele tentou alocar mais que RAM/2 e o kernel matou... 

Att, 


[1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting 


-- 
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ 
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento 

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

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

2017-04-20 Por tôpico Luiz Oliveira

O servidor Windows 2012 e para ajudar desabilitaram o firewall

Em 20 de abr de 2017 10:29 AM,  escreveu:

Caraca, isso aconteceu num servidor de uma empresa que trabalhei mas não
foi no DB foi em todos os arquivos doc, dat, excel, zip, pdf e varios
outros... o cara zipa praticamente tudo com criptografia forte e pede
resgate, não achei que isso aconteceria no PG, com certeza vão fazer em
outros bancos de dados tambem... eita nois, achei que fosse só no ambiente
windows


Marcelo

*From:* Pedro B. Alves
*Sent:* Thursday, April 20, 2017 9:40 AM
*To:* Comunidade PostgreSQL Brasileira
*Subject:* Re: [pgbr-geral] RES: RES: PostgreSQL ataque???



Em qui, 20 de abr de 2017 às 09:38, Santiago - NSR 
escreveu:

> Nos log do postgresql vc poderá ver a data e hora...no meu caso foi as
> 19:19:00 do dia 19.
>
>
>
>
>


Sim, vi a hora foi mais ou menos esse horário tb, mas é relevante em algo?


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

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

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

2017-04-20 Por tôpico Luiz Oliveira

Sim

O pessoal do sistema deixou o pg_hba aberto sem precisar de senha o cliente
sofreu um ataque e apagaram várias tabelas até para o banco, tive que
restaurar um backup .

Em 20 de abr de 2017 9:30 AM, "Rodrigo Della Justina" <
rodrigodellajust...@gmail.com> escreveu:

> Sim
>
> Aconteceu isso ontem em um ambiente de testes meu
>
> 2017-04-20 8:54 GMT-03:00 Pedro B. Alves :
>
>> Pessoal alguém já passou por algo parecido, cheguei no escritório hoje e
>> as tabelas do banco sumiram...
>>
>> tem somente uma tabela "warning" com os seguintes dados
>>
>>
>> "Send 0.5 BTC to this address and go to this site
>> http://ann2hzqgedo3plvu.onion/ to recover your database! SQL dump will
>> be available after payment!";"1Djh8KTQFDjizvYMpdBQiNrLxiSg2gg86K";"
>> ecnsupp...@mai2tor.com"
>>
>>
>> Alguém já viu isso??
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> *Rodrigo Della Justina *
> Mobile 55 46 98801 6165
> rodrigodellajust...@gmail.com
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Convite para Pentaho Day Brasil 2017

2017-04-17 Por tôpico Daniel Luiz da Silva

Boa tarde, 
Márcio, 

Terá transmissão via internet, ou vídeos gravados das palestras? 

Obrigado. 


De: "Marcio Junior Vieira" <mar...@ambientelivre.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Segunda-feira, 17 de abril de 2017 13:21:43 
Assunto: [pgbr-geral] Convite para Pentaho Day Brasil 2017 



Olá Pessoal , 


Estamos organizando o Pentaho Day 2017 aqui em Curitiba, evidentemente o mesmo 
não e focado em banco de Dados mas sempre temos assuntos relacionados e os 
profissionais de nossa areá de analise de dados usam muito PostgreSQL para 
construção de seus DWs. 

Teremos algumas palestras interessantes que vem ao encontro de assuntos 
relacionados a BDs e tudo gratuito , financiado por uma rede de parceiros do 
evento. 


Serão quase 50 atividades entre palestras e mini cursos, entre os dias 11 e 12 
de Maio. 


Relacionai algumas para a comunidade PostgreSQL se interessar: 

- Estará presente Matt Casters , Criador da Ferramenta de ETL mais usada no 
Mundo o Kettle ou Pentaho Data Integration presente no evento. 

- Teremos uma palestra sobre Interest Graph realizada pelo CEO do Grupo NZN 
(Baixaki, TecMundo, Mega Curioso, Superdownloads, Click Jogos, entre outros) 


- O CEO da OLX vai falar sobre o Data Lake construído pela empresa. 

- 7 Cases de uso de Pentaho em Grandes empresas Brasileiras, 1 Chilena e 1 
Visão do uso mundialmente. 


- 10 Mini cursos , que abortam temas com usar Pentaho Community com NoSQL , e 
outro de como Popular seu DataWarehouse com Pentaho Data Integration 

- Teremos uma palestra de uma pesquisadora sobre Data Warehouse com NoSQL. 

Aos empreendedores teremos a visita pelo responsável pelo projeto da prefeitura 
de Curitiba do "Vale do Pinhão" que está em implementação na capital 
paranaense, que fará uma palestra sobre o projeto. 

Bom é isso! 

as inscrições e mais informações podem ser realizadas pelo site do evento : 
http://www.pentahobrasil.com.br 




Grato 






-- 
Marcio Junior Vieira - Data Scientist 
Ambiente Livre Tecnologia - Soluções em Software Livre 
http://www.ambientelivre.com.br 
Telefone: +55 41 3308-3438 
Twitter: @ambientelivre @marciojvieira skype: marciojv 
Blog: blogs.ambientelivre.com.br/marcio 
Facebook: http://www.facebook.com/ambientelivre 


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

-- 



Facebook | Twitter | Google+ | Linkedin | Youtube 

Daniel Luiz da Silva 
Administrador de Banco de Dados 
Departamento Data Center 
daniel.si...@ipm.com.br 
48 3031-7500 
___
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

2017-04-17 Por tôpico Luiz Carlos L. Nogueira Jr.

Instala o PGBAdger nele. A partir dele você poderá analisar melhor a
necessidade de índice, piores consultas, etc
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] mensagem de erro: out of memory while reading tuples

2017-04-12 Por tôpico Luiz Henrique

Pessoal,

Temos aplicação Cliente/Servidor (Delphi com postgresql 8). De uns 5 dias
para cá vem aparecendo a msg. abaixo na tela da aplicação

"insufficient memory for this operation"
"out of memory while reading tuples"

Que parâmetros no banco eu posso ajustar para contornar ?

Obrigado a todos que poderem ajudar



Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dump sem índices/constraints

2017-03-31 Por tôpico Luiz Carlos L. Nogueira Jr.

pg_dump -t foo --section=pre-data --section=data -f /tmp/foo.data bench

ficou da forma que pensei.

Valeu!

Em 31 de março de 2017 18:18, Euler Taveira <eu...@timbira.com.br> escreveu:

>
> Em 31 de março de 2017 17:16, Luiz Carlos L. Nogueira Jr. <
> lcnogueir...@gmail.com> escreveu:
>
>> Existe alguma forma de fazer um pg_dump de uma tabela sem os
>> índices/contraints(PK)?
>> Ficaria só o CREATE TABLE e o COPY/INSERT dos dados
>>
>
> pg_dump -t foo --section=pre-data -f /tmp/foo.schema bench
> pg_dump -t foo --section=data -f /tmp/foo.data bench
>
>
> --
>Euler Taveira   Timbira -
> http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> <http://www.timbira.com.br>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Dump sem índices/constraints

2017-03-31 Por tôpico Luiz Carlos L. Nogueira Jr.

Caros,
Existe alguma forma de fazer um pg_dump de uma tabela sem os
índices/contraints(PK)?
Ficaria só o CREATE TABLE e o COPY/INSERT dos dados
Atenciosamente,
Luiz carlos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Duvidas com encoding UTF8 x LATIN1

2017-03-29 Por tôpico Luiz Henrique

Pessoal,

Estou iniciando testes no linux com Postgresql 9.4.Por questões de
compatibilidade com aplicação Delphi os bancos precisam estar em LATIN1.
Criei o banco em LATIN1. Na console psql aparece o erro ao testar o insert
abaixo:

insert into pessoa(pes_codpes,pes_nome) values ('50200','GIRÃO');

ERROR:  invalid byte sequence for encoding "UTF8": 0xc3 0x4f

Tem algum parâmetro que eu preciso configurar ?

Obrigado pela ajuda!




-- 
Atenciosamente,

Luiz Henrique
"In Medium Est Virtus!"
"A Virtude está no meio!"

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Livre
de vírus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
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úvidas WAL SENDER

2017-03-27 Por tôpico Luiz Carlos L. Nogueira Jr.

Sem as configurações fica difícil dizer algo. No entanto, o wal sender pode
"sumir" por um tempo se o postgres tiver que usar o restore_command para
reestabelecer a replicação.

Ele sumiu até o lento ficar sincronizado, mas não estava usando o archiving.
Como esse servidor "lento" seria apenas pra o uso em apenas um momento, não
deixei a partição de xlog separada (não preciso de performance e não sabia
até quanto ela iria crescer)
Aí ela cresceu muito, pois a taxa de xlog chegando é maior que o xlog
aplicado ao banco slave
Então o xlog chegou a mais de 200GB, aí depois de transmitir tudo que tinha
no master, foi baixando, baixando, até sincronizar.
Aí apareceu o WAL SENDER pro servidor lento

Em 26 de março de 2017 02:03, Euler Taveira <eu...@timbira.com.br> escreveu:

>
> Em 25 de março de 2017 17:59, Luiz Carlos L. Nogueira Jr. <
> lcnogueir...@gmail.com> escreveu:
>
>> Só tinha o WAL SENDER apontando pro slave rápido. O do lento "sumiu"
>
>
> Sem as configurações fica difícil dizer algo. No entanto, o wal sender
> pode "sumir" por um tempo se o postgres tiver que usar o restore_command
> para reestabelecer a replicação.
>
>
> --
>Euler Taveira   Timbira -
> http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> <http://www.timbira.com.br>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
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úvidas WAL SENDER

2017-03-25 Por tôpico Luiz Carlos L. Nogueira Jr.

Eu não entendi o que quis dizer aqui. "restart" em qual servidor?
Master

O que quis dizer com o resto da frase? Você fez um strace no processo do
wal sender para entender porque ele estava "parado"?

Só tinha o WAL SENDER apontando pro slave rápido. O do lento "sumiu"
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Dúvidas WAL SENDER

2017-03-24 Por tôpico Luiz Carlos L. Nogueira Jr.

Caros,
Seguem algumas dúvidas.
Ambiente: 1 master 2 slaves (1 com discos rápidos e outro com discos lentos)
A replicação fica "sincrona" com o disco rápido e "atrasada" com os discos
lentos, como já era de se esperar. (estou fazendo um load muito pesado e
não estou usando archiving)

Quando acabou o load, fiz um pg_ctl restart e depois de algum tempo notei
que o WAL SENDER parou pro slave "lento" e só voltou depois que todos os
XLOg foram aplicado no servidor lento.

Dúvidas:
Quando o WAL SENDER manda os WALS pros slaves?
Como saber se o WAL SENDER mandou todos os WALS para todos os slaves?


Porstgres 9.5

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

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

2017-03-14 Por tôpico Cleiton Luiz Domazak

2017-03-14 16:57 GMT-03:00 Alexsandro Haag :

> Em 14/03/2017 16:48, Rudimar escreveu:
>
>> Hoje rodo Vaccum e Reindex, não de forma automatizada. Eu tenho como
>> executar por automatizar esses comandos por um .bat ou script ?
>>
>
Você pode usar também o pgAgent [1].

1- https://www.pgadmin.org/docs/dev/pgagent.html

>
> Ola Rudimar,
>  pode criar um script batch e usar o Agendador de Tarefas do Windows para
> disparar conforme sua necessidade.
> ___
> 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] Tuning?

2017-03-11 Por tôpico Cleiton Luiz Domazak

2017-03-11 9:57 GMT-03:00 Pablo Sánchez :

> Caros,
>
> Estou com um pequeno probleminha de performance em importacao, que não tem
> relacão com o código, mas sim o Postgres.
>
> Basicamente é um CSV que popula uma tabela auto-relacional, o CSV tem
> 650.000 linhas
>
> No comeco a importacão estava indo bem (200 linhas por minuto), assim que
> chegou a 50.000 ja tinha caido para 120 por minuto, com 75.000 linhas, caiu
> para 80 por minuto e agora esta em 60 por minuto, o que mostra uma
> degradacao constante.
>

Seria muito útil você postar o comando, pois sem saber como a carga é
feita, não tem como fazer nenhuma análise.

Mas já tive esse problema quando a carga é feita com algum tipo de checagem
dos dados importados, pois conforme você faz a carga realmente pode ocorrer
uma degradação na performance, fazendo com que quanto mais dados você
insere, mais lento se torna a carga.

>
> Ja foram desativados todos os relacionamentos, todas as triggers, sequer
> foram criados indices ainda, ja foi feito renice dos processos ppara -19, o
> script de importacao mal come memoria para cachear alguns objetos de
> hierarquia mais alta (pais, estado, mmunicipio, cidade), ajustei
> shared_buffers e o escambal, e nada de aumentar a performance. Só faltaram
> agora tunnings de kernel do Linux mesmo.
>
> Comecamos a importar ontem as 16hs, e as 16h40 tinhamos umas 8000 linhas
> processadas ja, mas jah se passaram quase 21 horas e estamos so agora
> chegando nas 100.000 linhas. Nesse ritmo, soh vai terminar lah pelo fim de
> semana que vem.
>
> Alguém tem alguma sugestão que não essas já mencionadas, ou alguém saberia
> indicar o porque? Eu até já desativei o processamento das colunas de
> geography achando que poderia melhorar, mas sem melhora significativa (o
> que me rendeu algumas linhas perdidas e sem essa informacao, que depois eu
> dou um jeito manual de arrumar isso).
>
> --
>
>
>
>
>
> *Pablo Santiago Sánchez*
> ZCE ZEND006757
> phack...@gmail.com
> (61) 9843-0883
> http://www.sansis.com.br
> *"Pluralitas non est ponenda sine necessitate"*
>
> ___
> 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] MeetUp "Bate-papo sobre PostgreSQL" - 2ndQuadrant

2017-03-07 Por tôpico Cleiton Luiz Domazak

2017-03-07 15:24 GMT-03:00 William Ivanski :

> Agradeço a sugestão, Fabrizio!
>
> Eu não sei se podemos fazer isso. PgDays normalmente são organizados pela
> comunidade oficial do PostgreSQL Brasil ou da região.
>
> Outro ponto, não é um evento de um dia inteiro, é somente à noite, das 19h
> às 21h. Poderia ser PgNight, talvez, rss
>

Viajar para um "PgNight" ai dá problema em casa k

Brincadeiras a parte, grande iniciativa, estou mobilizando um pessoal pra
ir.

>
> Em ter, 7 de mar de 2017 às 14:48, Fabrízio de Royes Mello <
> fabri...@timbira.com.br> escreveu:
>
>>
>> 2017-03-07 14:36 GMT-03:00 William Ivanski :
>> >
>> > https://www.facebook.com/events/1291506420931048/
>> >
>> > Data: 16/03/2017 às 19:00 horas
>> > Local: Funpar - Sala 05 - R. João Negrão, 280, Centro, Curitiba - PR
>> >
>> > Agenda:
>> > - Disaster Recovery com Barman 2
>> > - PostgreSQL no Raspberry Pi
>> > - OmniDB: uma ferramenta web para gerenciamento e conversão de bancos
>> de dados
>> >
>> > Palestrantes: Rubens Souza (2ndQuadrant Itália), Rafael Castro, William
>> Ivanski
>> >
>> > Entrada Franca
>> >
>>
>> Show de bola a iniciativa, mas porque não nomear o encontro como um PDay
>> ??
>>
>> Att,
>>
>> --
>>Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
>>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> --
>
> William Ivanski - Microsoft MVP
>
> ___
> 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] Escalabilidade horizontal

2017-02-15 Por tôpico Luiz Carlos L. Nogueira Jr.

O que quero resolver é problema de CPU sem mexer na aplicação, pois vem de
terceiros,
Hoje tenho 36 CPUS e o Load Average e CPU pipocam, travando o servidor de
banco.
Eu sei que o armazenamento do RAC Oracle é centralizado (temos essa solução
também implementada para outras aplicações) e sei que o postgres não tem
essa estruturade armazenamento centralizado.
Por isso comecei jogando a possibilidade de um master-master síncrono, pois
é o que ainda vejo como uma possibilidade com o postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Escalabilidade horizontal

2017-02-15 Por tôpico Luiz Carlos L. Nogueira Jr.

Flávio,

Gostaria que minha aplicação apontasse pra um IP/porta e o Cluster fizesse
um balanceamento de carga e distribuisse entre os servidores (nós) onde
estão os bancos .
Quando os servidores de banco estivessem topados, poderia colocar mais uma
máquina para distribuir melhor o processamento.
Seria uma solução parecida com que a Oracle oferece (RAC)
A aplicação abstrairia de como o banco está (standalone ou vários nós de
banco). o importante pra ela seria um IP/Porta para conexão.

Acho que ficou mais claro agora
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Escalabilidade horizontal

2017-02-15 Por tôpico Luiz Carlos L. Nogueira Jr.

Existe também o Bucardo.

Mas não teria que modificar a aplicação, fora ser assincrona?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Escalabilidade horizontal

2017-02-15 Por tôpico Luiz Carlos L. Nogueira Jr.

Cleiton,

Não, é master x master mesmo (escrita em ambos)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Escalabilidade horizontal

2017-02-15 Por tôpico Cleiton Luiz Domazak

2017-02-14 22:57 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> Existe alguma solução de escalabilidade horizontal sem que tenhamos de
> alterar o código fonte da aplicação? Ficando transparente feito o pgbouncer.
>

Se for somente leitura, você pode utilizar o pgPool [1].

[1] - http://www.pgpool.net/mediawiki/index.php/Main_Page


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

[pgbr-geral] Escalabilidade horizontal

2017-02-14 Por tôpico Luiz Carlos L. Nogueira Jr.

Existe alguma solução de escalabilidade horizontal sem que tenhamos de
alterar o código fonte da aplicação? Ficando transparente feito o pgbouncer.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Log Repetido com temp files

2017-02-14 Por tôpico Luiz Carlos L. Nogueira Jr.

Em 14 de fevereiro de 2017 14:34, Euler Taveira <eu...@timbira.com.br>
escreveu:

> On 14-02-2017 13:34, Luiz Carlos L. Nogueira Jr. wrote:
> > Justamente isso. No PGBadger aparecem 21 consultas, mas foi apenas uma.
> > Uma pessoa que não conheça o ambiente não vai poder analisar o resultado
> > do PGbadger corretamente.
> >
> Se aparece é um bug no pgBadger. Você está usando a última versão? Qual
> é o seu log_line_prefix?
>
>

log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u@%r %x:%v '




Report generated by pgBadger 9.1 <http://dalibo.github.com/pgbadger/>



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

Re: [pgbr-geral] Log Repetido com temp files

2017-02-14 Por tôpico Luiz Carlos L. Nogueira Jr.

>
>
> Se você observar são arquivos temporários diferentes. A implementação de
> log_temp_files está a algumas camadas abaixo da que executa a consulta e
> não consegue relacionar a consulta com n arquivos temporários gerados
> (sendo n > 1). Repetir a consulta pode parecer ruim mas se houvesse um
> agrupamento por consulta dificultaria a vida das ferramentas que fazem
> anáĺise de logs como pgBadger.
>


Euler,
Justamente isso. No PGBadger aparecem 21 consultas, mas foi apenas uma. Uma
pessoa que não conheça o ambiente não vai poder analisar o resultado do
PGbadger corretamente.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Log Repetido com temp files

2017-02-14 Por tôpico Luiz Carlos L. Nogueira Jr.

Pessoal,

Eu coloco um comando pra rodar 1 só vez, só que ele aparece no log várias
vezes . Qual o motivo disso?



...
2017-02-13 22:06:58 BRT [41505]: [7-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 STATEMENT:  delete from jbpm_variableinstance va1
where id_ in
   (
   select va.id_ from jbpm_variableinstance va inner join
jbpm_processinstance pi on pi.id_ = va.processinstance_
   where pi.end_ is not null and va.name_ <> 'processo'
   );
2017-02-13 22:07:00 BRT [41505]: [8-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 LOG:  temporary file: path
"base/pgsql_tmp/pgsql_tmp41505.3", size 205767540
2017-02-13 22:07:00 BRT [41505]: [9-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 STATEMENT:  delete from jbpm_variableinstance va1
where id_ in
   (
   select va.id_ from jbpm_variableinstance va inner join
jbpm_processinstance pi on pi.id_ = va.processinstance_
   where pi.end_ is not null and va.name_ <> 'processo'
   );
2017-02-13 22:07:00 BRT [41505]: [10-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 LOG:  temporary file: path
"base/pgsql_tmp/pgsql_tmp41505.1", size 50221908
2017-02-13 22:07:00 BRT [41505]: [11-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 STATEMENT:  delete from jbpm_variableinstance va1
where id_ in
   (
   select va.id_ from jbpm_variableinstance va inner join
jbpm_processinstance pi on pi.id_ = va.processinstance_
   where pi.end_ is not null and va.name_ <> 'processo'
   );
2017-02-13 22:07:02 BRT [41505]: [12-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 LOG:  temporary file: path
"base/pgsql_tmp/pgsql_tmp41505.5", size 205596600
2017-02-13 22:07:02 BRT [41505]: [13-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 STATEMENT:  delete from jbpm_variableinstance va1
where id_ in
   (
   select va.id_ from jbpm_variableinstance va inner join
jbpm_processinstance pi on pi.id_ = va.processinstance_
   where pi.end_ is not null and va.name_ <> 'processo'
   );
2017-02-13 22:07:02 BRT [41505]: [14-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 LOG:  temporary file: path
"base/pgsql_tmp/pgsql_tmp41505.0", size 50315436
2017-02-13 22:07:02 BRT [41505]: [15-1] db=pje_jud1g_p,user=postgres@[local]
473469910:19/1064611 STATEMENT:  delete from jbpm_variableinstance va1
where id_ in
   (
   select va.id_ from jbpm_variableinstance va inner join
jbpm_processinstance pi on pi.id_ = va.processinstance_
   where pi.end_ is not null and va.name_ <> 'processo'
   );
...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Acessa banco em outra pasta

2017-02-09 Por tôpico Cleiton Luiz Domazak

2017-02-09 15:37 GMT-02:00 Franklin Anderson de Oliveira Souza <
frankli...@gmail.com>:

> Diretório é mais correto que dizer pasta ! :D
>

E o correto é não fazer top list para dizer isso :D. Inclusive é realmente
pasta, uma vez que o amigo está utilizando Windows, pelo que entendi do
contexto.

>
> Em 23 de janeiro de 2017 07:46, Rodrigo Della Justina <
> rodrigodellajust...@gmail.com> escreveu:
>
>> Olá
>>
>> Essa dúvida já rolou aqui no grupo, verifique o link abaixo que tem os
>> passos para você
>> acessar através da pasta da Data.
>>
>> https://listas.postgresql.org.br/pipermail/pgbr-geral/2010-J
>> anuary/019302.html
>>
>>
>>
>> Em 23 de janeiro de 2017 08:35, Saulo Morais 
>> escreveu:
>>
>>> >>Tenho o postgresql instalado e recebi de um cliente contendo a pasta
>>> >>data, como faço para acessar esses dados usando o pgadmin
>>>
>>> Você deve ter a mesma versão do PG que seu cliente.
>>>
>>> Após ligar o pc, encerre o serviço do PG.
>>>
>>> Vá no Prompt de Comando (cmd).
>>>
>>> Vá na pasta BIN do PG e inicie o serviço apontando para a pasta do
>>> cliente: pg_ctl -D 'pasta_data' start
>>>
>>>
>>> At.te,
>>> *Saulo Morais*
>>>
>>> --
>>> *De:* pgbr-geral  em nome
>>> de Andre Lucas 
>>> *Enviado:* sábado, 21 de janeiro de 2017 13:35:18
>>> *Para:* Comunidade PostgreSQL Brasileira
>>> *Assunto:* [pgbr-geral] Acessa banco em outra pasta
>>>
>>> Ola a todos
>>>
>>> Tenho o postgresql instalado e recebi de um cliente contendo a pasta
>>> data, como faço para acessar esses dados usando o pgadmin
>>>
>>>
>>> Atenciosamente
>>>
>>> André Lucas Souza.
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> *Rodrigo Della Justina *
>> Mobile 55 46 98801 6165 <(46)%2098801-6165>
>> rodrigodellajust...@gmail.com
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> foobar
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Temporary table no slave

2017-02-09 Por tôpico Luiz Carlos L. Nogueira Jr.

Pessoal,

Existe alguma perspectiva do Postgres permitir a criação de temporary
tables num banco slave?


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

[pgbr-geral] COSIF - Atualização de dados

2017-02-07 Por tôpico Rodrigo Luiz Frey

Amigos.

Alguem já teve a necessidade de atualizar o PLANO COSIF em seu banco de
dados (http://www3.bcb.gov.br/aplica/cosif).

Tenho esta necessidade, mas não sei onde posso conseguir esta informação
via serviço web.
Atualmente busco o Plano Contábil atualizado através do site do Banco
Central,
atualizando conforme necessidade (Conta não existe no meu banco, copio "a
mão" do site acima citado).

Alguém sabe algum serviço web neste sentido?

PS: Talvez não entre nos temas da lista, mas pode ser que alguém tenha a
mesma problemática.



*Rodrigo Luiz Frey*

Aluno de Sistemas de Informação - FACCAT
Skype: rodrigoluizfrey
Tel.: +55 51 9903 7888
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Estratégia para vacuum full com replicação

2017-02-07 Por tôpico Luiz Carlos L. Nogueira Jr.

Entendi agora o arquivamento da forma correta.
Apesar do delay entre o slave e o master ficar crescendo mesmo com o slave
aplicando os archives, é como se o postgres só ajustasse esse tempo quando
o vacuum da tabela é finalizado.
O delay chegou a mais de 1h, mas quando passou dessa tabela (160GB) ele
voltou a ficar perto de 0.
O tamanho máximo da pasta de arquivamento nem chegou a 5GB, muito menor que
a minha maior tabela.

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

Re: [pgbr-geral] Perder Dados

2017-02-06 Por tôpico Luiz Carlos L. Nogueira Jr.

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

Re: [pgbr-geral] Estratégia para vacuum full com replicação

2017-02-05 Por tôpico Luiz Carlos L. Nogueira Jr.

>
> Não use wal_keep_segments. Ao invés disso, utilize arquivamento (< 9.4)
> ou slots (>= 9.4).
>
>
 Se você está usando arquivamento basta configurar o parâmetro

> restore_command no recovery.conf do servidor secundário. O comando a ser
> informado deve buscar onde você está arquivando os logs de transação. Ex.:
>




> Eu uso arquivamento, só que não tenho área suficiente pra aguentar todo o
> vacuum.
>
> restore_command = 'scp postgres@primario:/archives/%f %p'
>
>
>
> PS> fazer VF? Existe tanto inchaço assim nessas duas tabelas? 99% das
> execuções de VF, são feitas sem necessidade. Inchaço é inerente ao MVCC,
> portanto, a ideia é contê-lo e não removê-lo.
>
> Como disse ordens superiores de "não técnicos"


 Mas, aquela estratégia de ficar criando e apagando outra tabela, funciona
mesmo ou foi sorte?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Estratégia para vacuum full com replicação

2017-02-03 Por tôpico Luiz Carlos L. Nogueira Jr.

>
>
> Você pode simplesmente ajustar o parâmetro wal_keep_segments, caso vc
> tenha espaço em disco para isso claro, e manter mais WALs, assim mesmo em
> momentos em que o volume de WAL gerado é grande, você não perderá a
> replicação.
>
>
Meu wal_keep_segments = 64

No meu archive_command eu copio também para outra pasta, fora a que faço o
backup, mas só que terão ficarão muitos archives lá.

>
>
> Qual a versão do seu PostgreSQL?
>

9.3.12

O que notei é que no vacuum de uma tabela ele só vai pro slave quando
acaba, e como eu tenho tabelas maiores que minha área de xlog, não dá pra
manter o sincronismo. Só consegui com aquela "gambiarra" de ficar criando e
apagando uma tabela em outro banco do master
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Estratégia para vacuum full com replicação

2017-02-03 Por tôpico Cleiton Luiz Domazak

2017-02-03 15:41 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> Pessoal,
>
> O ambiente é o seguinte:
>
> 1-Tenho 500GB de dados (área para dados 1.2TB)
> 2-Maiores tabelas 2 de 200GB
> 3-pg_xlog 20GB
>
> Gostaria e fazer um vacuum full "transparente" na replicação e não sei se
> a estratégia que uso é a melhor.
>
> Uma vez que fiz numa base menor, notei que o delay entre o master e o
> slave começou a ficar grande e terminei perdendo a replicação por falta de
> WAL.
>

Você pode simplesmente ajustar o parâmetro wal_keep_segments, caso vc tenha
espaço em disco para isso claro, e manter mais WALs, assim mesmo em
momentos em que o volume de WAL gerado é grande, você não perderá a
replicação.

Eu já tive problemas em ambientes inclusive em que eu não conseguia criar
um base backup, por conta do volume de dados ser elevado, e em poucos
minutos eu perdia o sincronismo.


> Uma estratégia que usei uma vez foi ficar criando e dropando uma tabela no
> master (em outro banco sem ser o do vacuum) pois isso forçava o WAL a ser
> aplicado no slave, independente do que ele estivesse sendo feito no master.
> Fazia isso de 1 em 1 minuto e notei que o delay entre o slave e o master
> voltava a ficar perto de 0.
>
> A opção de fazer o vacuum full não foi por questões técnicas e sim uma
> ordem de cima pra baixo
>
> Qual seria a melhor estratégia para fazer o vacuum full a utilizar sem
> modificar minha estrutura de replicação?
>

Qual a versão do seu PostgreSQL?

Dependendo da versão você pode utilizar novas funcionalidades que irão te
ajudar a manter a replica, mas tudo o que disse até aqui, vai te demandar
mais espaço em disco no Master.


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

[pgbr-geral] Estratégia para vacuum full com replicação

2017-02-03 Por tôpico Luiz Carlos L. Nogueira Jr.

Pessoal,

O ambiente é o seguinte:

1-Tenho 500GB de dados (área para dados 1.2TB)
2-Maiores tabelas 2 de 200GB
3-pg_xlog 20GB

Gostaria e fazer um vacuum full "transparente" na replicação e não sei se a
estratégia que uso é a melhor.

Uma vez que fiz numa base menor, notei que o delay entre o master e o slave
começou a ficar grande e terminei perdendo a replicação por falta de WAL.

Uma estratégia que usei uma vez foi ficar criando e dropando uma tabela no
master (em outro banco sem ser o do vacuum) pois isso forçava o WAL a ser
aplicado no slave, independente do que ele estivesse sendo feito no master.
Fazia isso de 1 em 1 minuto e notei que o delay entre o slave e o master
voltava a ficar perto de 0.

A opção de fazer o vacuum full não foi por questões técnicas e sim uma
ordem de cima pra baixo

Qual seria a melhor estratégia para fazer o vacuum full a utilizar sem
modificar minha estrutura de replicação?

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

Re: [pgbr-geral] RESTAURAR BACKUP

2017-01-25 Por tôpico Michel Luiz Milezzi

Antes de mais nada, sugiro que você não confie no gerenciamento de serviços
do Windows. Tente subir o banco manualmente pelo prompt de comandos:
Entre no prompt com um usuário que não seja administrador (non super-user),
navegue até a pasta bin do Postgres e execute o comando: postgres -D

Dependendo da sua configuração de log, a mensagem de erro vai aparecer no
próprio prompt ou na pasta pg_log. Verifique lá o erro exato que está
acontecendo e nos diga.



Em 25 de janeiro de 2017 12:50, Ronei Heck <ro...@rhsistemas.com.br>
escreveu:

> E se tentar o autovacuum=off do arquivo postgresql.conf? Digo isso, porque
> em um cliente meu estava travando o serviço do postgres, e passou a
> funcionar normalmente colocando o autovacuum=off.
>
> Att.
>
> Ronei Heck
>
>
> *From:* José Mello Júnior <jose.mello.jun...@gmail.com>
> *Sent:* Wednesday, January 25, 2017 11:29 AM
> *To:* Comunidade PostgreSQL Brasileira
> <pgbr-geral@listas.postgresql.org.br>
> *Subject:* Re: [pgbr-geral] RESTAURAR BACKUP
>
> Cleiton,
>
> Quando falei da pasta data, me refiro à instalação padrão, nesse caso fica
> dentro da própria árvore de pastas à partir da pasta 9.4 e nesse caso
> somente o tablespace default estava sendo utilizado.
>
> Procedimento manual foi realizado com a nova instalação do Banco, onde
> apenas renomeio a pasta de data para data_new e de data_old para data, onde
> a data_old são os dados que necessito acessar. Antes de fazer esse processo
> é sempre parado o serviço, por esse motivo é que ao tetar reativar o
> serviço vem a mensagem que foi iniciado e interrompido.
>
> Efetivamente nos LOG´s do Banco não aparece nem mesmo a tentativa de
> iniciar o Banco, mas, um colega da lista me indicou para eu olhar nos
> eventos do Windows e vem a mensagem que "parece que o postmaster já está
> sendo utilizado", mas não tem qualquer arquivo .PID na estrutura.
>
> Muito obrigado pela atenção.
>
> Att
>
>
>
> Em 25 de janeiro de 2017 10:58, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>>
>>
>> 2017-01-25 8:54 GMT-02:00 José Mello Júnior <jose.mello.jun...@gmail.com>
>> :
>>
>>> Ainda não consegui recuperar o Banco de Dados, minhas ideias acabaram,
>>> alguém pode me dar alguma outra luz?
>>>
>>
>> Vc chegou a fazer o procedimento manualmente de backup e testar se volta?
>>
>> Pare o serviço, faça a copia(crtl-c + crtl+v), compacte, renomeie,
>> descompacte e tenta subir, claro que fazendo isso com a pasta "data" que
>> está funcionando.
>>
>> Se funcionar, executa novamente o seu script e veja se o erro ocorre
>> novamente.
>>
>> Digo isso, pq já fiz esse processo várias vezes, e não tem muito o que
>> dar errado, inclusive quando para o serviço do Windows o postmaster.pid é
>> deletado automaticamente.
>>
>> E por nem gravar log do PostgreSQL, está parecendo que alguma coisa pode
>> ter sido corrompido no processo, ou alguma permissão que o seu script acaba
>> alterando, mesmo sem a sua vontade.
>>
>> Outra dúvida, quando vc se refere a pasta "data", seria o seu
>> "data_directory", ou é a pasta com tablespaces? Pergunto, pq já vi confusão
>> com isso.
>>
>>
>>>
>>> Muito Obrigado
>>>
>>>
>>> Em 24 de janeiro de 2017 14:42, José Mello Júnior <
>>> jose.mello.jun...@gmail.com> escreveu:
>>>
>>>> Sim, esse macete eu já sabia por mensagens anteriores aqui do grupo.
>>>>
>>>> Att
>>>>
>>>> Em 24 de jan de 2017 14:35, "Alexsandro Haag" <
>>>> alexsandro.h...@gmail.com> escreveu:
>>>>
>>>>>
>>>>> Em 24 de janeiro de 2017 14:21, Rosana de Oliveira <
>>>>>> rosana.pi...@gmail.com <mailto:rosana.pi...@gmail.com>> escreveu:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Em 24 de janeiro de 2017 14:10, José Mello Júnior
>>>>>> <jose.mello.jun...@gmail.com <mailto:jose.mello.jun...@gmail.com
>>>>>> >>
>>>>>> escreveu:
>>>>>>
>>>>>> No evento do Windows encontrei a seguinte mensagem:
>>>>>>
>>>>>> pg_ctl: este diretório de dados parece já estar executando um
>>>>>> postmaster
>>>>>>
>>>>>> o que posso fazer?
>>>>>>
>>>>>> Olá José,
>>>>>   e as permissões na pasta que você restauro

Re: [pgbr-geral] RESTAURAR BACKUP

2017-01-25 Por tôpico Cleiton Luiz Domazak

2017-01-25 8:54 GMT-02:00 José Mello Júnior :

> Ainda não consegui recuperar o Banco de Dados, minhas ideias acabaram,
> alguém pode me dar alguma outra luz?
>

Vc chegou a fazer o procedimento manualmente de backup e testar se volta?

Pare o serviço, faça a copia(crtl-c + crtl+v), compacte, renomeie,
descompacte e tenta subir, claro que fazendo isso com a pasta "data" que
está funcionando.

Se funcionar, executa novamente o seu script e veja se o erro ocorre
novamente.

Digo isso, pq já fiz esse processo várias vezes, e não tem muito o que dar
errado, inclusive quando para o serviço do Windows o postmaster.pid é
deletado automaticamente.

E por nem gravar log do PostgreSQL, está parecendo que alguma coisa pode
ter sido corrompido no processo, ou alguma permissão que o seu script acaba
alterando, mesmo sem a sua vontade.

Outra dúvida, quando vc se refere a pasta "data", seria o seu
"data_directory", ou é a pasta com tablespaces? Pergunto, pq já vi confusão
com isso.


> Muito Obrigado
>
>
> Em 24 de janeiro de 2017 14:42, José Mello Júnior <
> jose.mello.jun...@gmail.com> escreveu:
>
>> Sim, esse macete eu já sabia por mensagens anteriores aqui do grupo.
>>
>> Att
>>
>> Em 24 de jan de 2017 14:35, "Alexsandro Haag" 
>> escreveu:
>>
>>>
>>> Em 24 de janeiro de 2017 14:21, Rosana de Oliveira <
 rosana.pi...@gmail.com > escreveu:



 Em 24 de janeiro de 2017 14:10, José Mello Júnior
 >
 escreveu:

 No evento do Windows encontrei a seguinte mensagem:

 pg_ctl: este diretório de dados parece já estar executando um
 postmaster

 o que posso fazer?

 Olá José,
>>>   e as permissões na pasta que você restaurou do backup... Estão
>>> adequadas para o Postgres?
>>>
>>> Alex
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> Mello Júnior
> 41.3252-3555 <(41)%203252-3555>
>
> ___
> 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] Ajuda com definição

2017-01-24 Por tôpico Jorge Luiz

Ao que parece pretende-se checar se o número de caracteres desse atributo é
igual a 5 ou igual a 7 e se todos são caracteres do tipo numérico.
Possivelmente pode-se fazer essa checagem de alguma forma no banco de dados
(não sou profundamente conhecedor do Postgres). No entanto sei que,
geralmente, um banco de dados está associado a alguma aplicação que fornece
uma interface para entrada dos mesmos (linguagens tais como
java/javaEE/JSP/JSF, C/C++, php, python etc). Sendo assim, poderia se
considerar fazer essa checagem (validação) no programa, caso a interface
ainda esteja em desenvolvimento. Acho que nem tudo precisa ser
rigorosamente implementado no banco de dados. Por exemplo: validação de CPF
pode ser colocada no próprio BD (já vi um código assim na internet), mas
acho mais fácil implementar isso na aplicação

Em 24 de janeiro de 2017 22:48, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le mar. 24 janv. 2017 à 23:12, Marcio A. Sepp <
> mar...@zyontecnologia.com.br> a écrit :
>
>> Peço desculpas, mas não consegui organizar o e-mail direito.
>>
>
> Acontece.  Só procure pensar em quem lerá.
>
>
> O caso eh que tem um cadastro de itens onde o código do item pode vir com
>> 5 ou com 7 dígitos. Quando o item eh de um determinado importador ele tem 5
>> dígitos e qdo eh do mercado interno ele tem 7.
>> Exemplo d código d produto com 7 dígitos: 0012345.
>> Exemplo d código d produto com 5 dígitos: 01234
>>
>> O que eh melhor (ou mais correto a fazer neste caso):
>> 1) crio um campo para identificar a origem (importador "xxx" ou mercado
>> interno) e junto esse campo na chave. A chave seria composta pelo campo
>> origem e o campo código do item (neste caso integer);
>>
>
> Essa é uma solução interessante.  Se o zero à esquerda não for
> significativo, e se não for o caso de separar esse cadastro em duas
> entidades, pode ser ideal.
>
>
> 2) crio o campo código como sendo varchar(7);
>>
>
> Se os zeros à esquerda forem significativos, por exemplo se essa lógica
> que delineaste acima for não apenas incidental mas uma regra de negócio,
> pode ser a solução ideal, já que nesse caso o atributo de origem se
> depreenderia do tamanho da seqüência de caracteres.
>
> Mas, pensando melhor, do jeito que explicaste, parece ser uma
> regra de negócio.  Se não houver diferenças noutros atributos (atributos
> preenchidos ou NULL de acordo com a origem, ou de significados dependentes
> da origem), eu creio que manteria como seqüência de caracteres.  Mas, se
> houver diferenças noutros atributos, talvez fosse o caso de normalizar.  De
> qualquer maneira, sendo uma regra de negócio, um atributo origem explícito
> seria redundante com o tamanho do código, não?  Independente dele ser
> armazenado como número ou seqüência de caracteres.
>
> É bem difícil aconselhar modelagem por correio eletrônico, costuma
> faltar informação.
>
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org
> +55 (61) 99302 2691 ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



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

Re: [pgbr-geral] not null if

2017-01-19 Por tôpico Cleiton Luiz Domazak

2017-01-19 10:55 GMT-02:00 Rafael Sousa :

> é possivel colocar um not null apenas se outro campo for por exemplo true ?
>

Você poderia ser mais claro no exemplo?

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

Re: [pgbr-geral] armazenar Plano execução

2017-01-10 Por tôpico Cleiton Luiz Domazak

2017-01-10 11:35 GMT-02:00 Neto pr :

> Ola pessoal
>
> No meu trabalho de Pós, preciso armazenar os planos de execucoes das
> consultas submetidas (explain consulta).
> Nao gostaria de armazenar o plano de execucao em texto puro, pois
> somente alguns dados que me interessam, como por exemplo o custo total
> da consulta.
>
> Alguem tem alguma sugestao para armazenar o plano de execucao no banco
> de dados, separado em campos como: textosql, custo total, tempo,
> etc...
>

Dê uma olhada no [1] auto_explain se não lhe atende


> Caso nao encontre uma solucao melhor, vou ter que varrer a string
> texto (saida do comando explain), para encontrar o custo total, tempo
> etc.. para apos armazenar em uma tabela no banco de dados.
>
> []`s Neto
>

1- https://www.postgresql.org/docs/9.2/static/auto-explain.html


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

[pgbr-geral] execução de checkpoint constantes

2016-12-21 Por tôpico Luiz Henrique

Prezados,

Temos Postgresql 9.1 no Linux CentOS. Analisando o log observamos a
execução do checkpoint diversas (muitas) vezes ao dia durante pequenos
espaço de tempo (5 minutos em média). Estou com suspeita que a aplicação
esta sendo impactada durante o processo.

LOG:  checkpoint starting: time
LOG:  checkpoint complete:

Atualmente, no postgresql.conf está assim :

checkpoint_segments = 32
checkpoint_timeout = 30min
checkpoint_completion_target = 0.9
#checkpoint_warning = 30s
log_checkpoints = on

Dúvidas :

1.isso é saudável ?
2.pode atrapalhar a performance do banco ?
3.que parâmetro (e como) eu devo alterar para "aumentar/esticar" o tempo
entre cada checkpoint ?

Agradeço pelas dicas!!!
Grato!

-- 
Atenciosamente,
Luiz Henrique
___
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 alteração de parâmetros postgresql.conf

2016-12-16 Por tôpico Cleiton Luiz Domazak

2016-12-16 14:23 GMT-02:00 Luiz Henrique <luiz.henriqu...@gmail.com>:

> Pessoal,
>
> Tenho Postgresql 9.1 rodando em CentOS. 2 dúvidas em relação a alterações
> no postgresql.conf
>
> 1. após realizar alteração no postgresql.conf e aplicar o reload
> (/etc/init.d/postgresql reload), caso algum parâmetro tenha sido colocado
> ou alterado de forma incorreta. O banco vai parar ou rejeitar a alteração ?
> Reload não vai acontecer ?
>

O comando incorreto será ignorado apenas e uma entrada no log irá ser
gerada. Como no exemplo:

< 2016-12-16 11:28:45.011 EST > LOG:  invalid value for parameter
"work_mem": "200M"
< 2016-12-16 11:28:45.011 EST > HINT:  Valid units for this parameter are
"kB", "MB", "GB", and "TB".
< 2016-12-16 11:28:45.011 EST > LOG:  configuration file
"/storage/9.6/data/postgresql.conf" contains errors; unaffected changes
were applied


>
> 2. a alteração do parâmetro max_connections exige restart ou basta reload ?
>
>
Isso, exige restart. Você pode observar se o parâmetro necessita de restart
ou não nesta documentação [1].



[1] - https://www.postgresql.org/docs/9.1/static/view-pg-settings.html


> Grato pela ajuda!
>
> Abs!
>
> Luiz Henrique
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] dúvida alteração de parâmetros postgresql.conf

2016-12-16 Por tôpico Luiz Henrique

Pessoal,

Tenho Postgresql 9.1 rodando em CentOS. 2 dúvidas em relação a alterações
no postgresql.conf

1. após realizar alteração no postgresql.conf e aplicar o reload
(/etc/init.d/postgresql reload), caso algum parâmetro tenha sido colocado
ou alterado de forma incorreta. O banco vai parar ou rejeitar a alteração ?
Reload não vai acontecer ?

2. a alteração do parâmetro max_connections exige restart ou basta reload ?

Grato pela ajuda!

Abs!

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

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

2016-12-16 Por tôpico Cleiton Luiz Domazak

2016-12-15 16:48 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:




> 2016-12-15 11:23 GMT-02:00 Tiago José Adami <adam...@gmail.com>:
>
>> Em 15 de dezembro de 2016 09:26, Cleiton Luiz Domazak
>> <cleitondoma...@gmail.com> escreveu:
>> >> Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a
>> >> definição (comando) que você usou para criar o índice?
>> >
>> > Foi a primeira coisa a ser feita, fiz VACUUM, VACUUM FULL, ANALYZE,
>> REINDEX, o pacote completo .
>> >
>> > O indice foi criado apenas em cima do campo data, sem nenhum tipo de
>> formatação ou filtro.
>>
>> Ok. Isto deveria ter causando algum efeito.
>>
>> >> > Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre
>> no meu ambiente de testes. E ocorre em situações um pouco aleatórias.
>> >> >
>> >> > Essas são as datas que eu usei e se funcionou ou não. Muito
>> esquisito.
>> >> >
>> >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK
>> >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK
>> >> > AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK
>> >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK
>> >> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK
>> >> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK
>> >>
>> >> Qual a quantidade de registros total na tabela e a média mensal?
>> >
>> > Se você observar, se aumentar o range de data, a query fica rápida.
>> >>
>> >> Primeiro execute um VACUUM ANALYZE sobre a tabela como mencionei antes
>> >> e depois roda um EXPLAIN para vermos o que o plano de acesso está
>> >> fazendo para pelo menos uma consulta que ficou OK e para a NOK.
>> >
>> > Consegui finalmente rodar o EXPLAIN ANALYZE, e o plano realmente muda,
>> agora vou ver o que mudou e pq.
>>
>> Desculpe, por um momento esqueci que o EXPLAIN não concluía. De acordo
>> com as suas informações, se a tabela não possui nenhuma peculiaridade,
>> há grandes chances de ser algum bug no PostgreSQL.
>>
>
> Testei em um server com a ultima release 9.4.10 e o mesmo problema ocorre.
>
>
>>
>> Antes de analisar o resultado do EXPLAIN, que tal tentar o seguinte:
>>
>> 1) Alterar o predicado da consulta para AND DR.DTINSERT BETWEEN
>> '2016-10-30' AND '2016-11-01'. Por gentileza informe se houve algum
>> resultado positivo ou negativo.
>>
>
> Já havia feito esse teste, mas como já fiz tanta coisa que já não lembrava
> refiz , e o problema ainda assim ocorre.
>
>>
>> 2) Instalar mesma versão 9.4.9 em uma outra máquina (talvez uma
>> máquina virtual?) com SO compatível ao seu ambiente de produção
>> (Windows ou Linux ou Unix) e importar o dump (pode ser apenas a tabela
>> em questão) para tentar reproduzir o erro;
>>
>
> Como ocorreu o mesmo problema em outra vesão e outro server, acabei
> eliminando essa possibilidade
>
>>
>> 3) Se o erro persistir, atualize o PostgreSQL para a versão 9.4.10 e
>> refaça o teste;
>>
>
> Feito, e ocorre o mesmo erro.
>
>>
>> 4) Se o erro persistir, instale então a versão 9.5.5 e depois a versão
>> 9.6.1, importe novamente dump e refaça o teste para as duas versões;
>>
>
> Vou fazer um teste na versão 9.6, no mesmo server de teste, tenho um
> cluster da 9.6 no ar.
>
>>
>> Em qualquer momento, se o problema não ocorrer mais, saberemos que já
>> existe uma versão já com esta anomalia corrigida - então sugiro
>> proceder com a atualização.
>>
>> Caso nenhuma das alternativas apresente uma solução é muito importante
>> coletar o máximo de informações, descrever todas as etapas já
>> realizadas nos testes e submeter o erro para a lista oficial de bugs
>> [1] (em inglês, claro) seguindo as recomendações [2].
>>
>
> Esses são os EXPLAINs gerados na query completa.
>
> EXPLAIN NOK - https://explain.depesz.com/s/YRnJ
> EXPLAIN OK   - https://explain.depesz.com/s/dHqS
>
> O que observei é que na query NOK, ao invés de o plano realizar um MERGE
> JOIN, ele fez vários NESTED LOOP e ai que o bixo pega. Lembrando que na
> query que ocorre o problema o range de data e consequentemente a quantidade
> de dados é menor.
>



Galera, problema resolvido, e da forma mais vergonhosa possível ,
era apenas um LEFT JOIN fora do lugar, como a query é gerada, tinha ficado
um LEFT largado e acabava mudando o plano da query.

>
>
>> [1] mailto:pgsql-b...@postgresql.org
>> [2] https://www.postgresql.org/docs/9.4/static/bug-reporting.html
>>
>> Adami
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-12-16 Por tôpico Cleiton Luiz Domazak

2016-12-15 23:24 GMT-02:00 Euler Taveira :

> On 15-12-2016 10:16, Crauss, Jacson wrote:
> > Tablespace server antigo:
> > ~/dados/pg_tblspc/tblspc_pgh
> > $ du -skh
> > 411G.
> >
> Você e o Cleiton estão comentendo o mesmo erro: *não* se cria
> tablespaces dentro do diretório $PGDATA ou qualquer subdiretório dele
> (vide [1]). Muitos confundem o conceito do Oracle com Postgres e acham
> que o equivalente de DB_CREATE_FILE_DEST é $PGDATA/pg_tblspc; não é!  O
> diretório $PGDATA/pg_tblspc é de uso do postgres para armazenar os links
> para o caminho real das tablespaces. Aliás, *não* crie nada no $PGDATA a
> não ser que (i) esteja documentado ou (ii) que você saiba o que está
> fazendo.
>

Estou ciente da má pratica de criar a tablespace na PGDATA, mas
infelizmente é uma base de cliente, e foi configurada assim na época.


>
> euler=# create tablespace foo location '/tmp/teste/pg_tblspc/foo';
> AVISO:  tablespace location should not be inside the data directory
> CREATE TABLESPACE
>
> O postgres está contando duas vezes (uma para o seu diretório e outra
> para o link simbólico para esse diretório). É um bug? Você está fazendo
> algo não recomendado e que pode levar a algum comportamento inesperado
> de alguns programas.
>

O dobro do tamanho aparece quando executo o comando select
pg_size_pretty(pg_database_size('teste2'));

Neste comando ele calcula fisicamente o tamanho e conta os 2 diretórios?
Pra mim isso é novidade (e não estou sendo ironico k), eu realmente
achei que essa função calculava o tamanho da base logicamente.


>
> $ pg_basebackup -P -c fast -D /tmp/abc
> AVISO:  não pôde ler link simbólico "pg_tblspc/foo": Argumento inválido
> pg_basebackup: diretório "/tmp/teste/pg_tblspc/foo" existe mas não está
> vazio
> LOG:  não pôde enviar dados para cliente: Pipe quebrado
> ERRO:  cópia de segurança base não pôde enviar dados, interrompendo
> cópia de segurança
> FATAL:  conexão com cliente foi perdida
>
>
> [1]
> https://www.postgresql.org/message-id/CA%2BTgmobZLyLU8tFCbMqbjMWB6t%2B%
> 3DERaDo820uQEJCVAQK_Paow%40mail.gmail.com
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-12-15 Por tôpico Cleiton Luiz Domazak

2016-12-15 11:23 GMT-02:00 Tiago José Adami <adam...@gmail.com>:

> Em 15 de dezembro de 2016 09:26, Cleiton Luiz Domazak
> <cleitondoma...@gmail.com> escreveu:
> >> Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a
> >> definição (comando) que você usou para criar o índice?
> >
> > Foi a primeira coisa a ser feita, fiz VACUUM, VACUUM FULL, ANALYZE,
> REINDEX, o pacote completo .
> >
> > O indice foi criado apenas em cima do campo data, sem nenhum tipo de
> formatação ou filtro.
>
> Ok. Isto deveria ter causando algum efeito.
>
> >> > Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre
> no meu ambiente de testes. E ocorre em situações um pouco aleatórias.
> >> >
> >> > Essas são as datas que eu usei e se funcionou ou não. Muito esquisito.
> >> >
> >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK
> >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK
> >> > AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK
> >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK
> >> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK
> >> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK
> >>
> >> Qual a quantidade de registros total na tabela e a média mensal?
> >
> > Se você observar, se aumentar o range de data, a query fica rápida.
> >>
> >> Primeiro execute um VACUUM ANALYZE sobre a tabela como mencionei antes
> >> e depois roda um EXPLAIN para vermos o que o plano de acesso está
> >> fazendo para pelo menos uma consulta que ficou OK e para a NOK.
> >
> > Consegui finalmente rodar o EXPLAIN ANALYZE, e o plano realmente muda,
> agora vou ver o que mudou e pq.
>
> Desculpe, por um momento esqueci que o EXPLAIN não concluía. De acordo
> com as suas informações, se a tabela não possui nenhuma peculiaridade,
> há grandes chances de ser algum bug no PostgreSQL.
>

Testei em um server com a ultima release 9.4.10 e o mesmo problema ocorre.


>
> Antes de analisar o resultado do EXPLAIN, que tal tentar o seguinte:
>
> 1) Alterar o predicado da consulta para AND DR.DTINSERT BETWEEN
> '2016-10-30' AND '2016-11-01'. Por gentileza informe se houve algum
> resultado positivo ou negativo.
>

Já havia feito esse teste, mas como já fiz tanta coisa que já não lembrava
refiz , e o problema ainda assim ocorre.

>
> 2) Instalar mesma versão 9.4.9 em uma outra máquina (talvez uma
> máquina virtual?) com SO compatível ao seu ambiente de produção
> (Windows ou Linux ou Unix) e importar o dump (pode ser apenas a tabela
> em questão) para tentar reproduzir o erro;
>

Como ocorreu o mesmo problema em outra vesão e outro server, acabei
eliminando essa possibilidade

>
> 3) Se o erro persistir, atualize o PostgreSQL para a versão 9.4.10 e
> refaça o teste;
>

Feito, e ocorre o mesmo erro.

>
> 4) Se o erro persistir, instale então a versão 9.5.5 e depois a versão
> 9.6.1, importe novamente dump e refaça o teste para as duas versões;
>

Vou fazer um teste na versão 9.6, no mesmo server de teste, tenho um
cluster da 9.6 no ar.

>
> Em qualquer momento, se o problema não ocorrer mais, saberemos que já
> existe uma versão já com esta anomalia corrigida - então sugiro
> proceder com a atualização.
>
> Caso nenhuma das alternativas apresente uma solução é muito importante
> coletar o máximo de informações, descrever todas as etapas já
> realizadas nos testes e submeter o erro para a lista oficial de bugs
> [1] (em inglês, claro) seguindo as recomendações [2].
>

Esses são os EXPLAINs gerados na query completa.

EXPLAIN NOK - https://explain.depesz.com/s/YRnJ
EXPLAIN OK   - https://explain.depesz.com/s/dHqS

O que observei é que na query NOK, ao invés de o plano realizar um MERGE
JOIN, ele fez vários NESTED LOOP e ai que o bixo pega. Lembrando que na
query que ocorre o problema o range de data e consequentemente a quantidade
de dados é menor.


> [1] mailto:pgsql-b...@postgresql.org
> [2] https://www.postgresql.org/docs/9.4/static/bug-reporting.html
>
> Adami
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-12-15 Por tôpico Luiz Carlos L. Nogueira Jr.

Aqui tivemos um problema desses com uma tabela monstruosa que estourou a
partição no meio de um vacuum full..
Aí a tabela que seria duplicada pelo vacuum ficou "perdida", apenas
ocupando espaço, mas sem fazer nada.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-12-15 Por tôpico Cleiton Luiz Domazak

2016-12-14 19:40 GMT-02:00 Tiago José Adami <adam...@gmail.com>:

> Em 14 de dezembro de 2016 16:43, Cleiton Luiz Domazak
> <cleitondoma...@gmail.com> escreveu:
> > Nem index tinha, criei e ele não é utilizado.
>
> Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a
> definição (comando) que você usou para criar o índice?
>

Foi a primeira coisa a ser feita, fiz VACUUM, VACUUM FULL, ANALYZE,
REINDEX, o pacote completo .

O indice foi criado apenas em cima do campo data, sem nenhum tipo de
formatação ou filtro.

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

Se você observar, se aumentar o range de data, a query fica rápida.

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

Consegui finalmente rodar o EXPLAIN ANALYZE, e o plano realmente muda,
agora vou ver o que mudou e pq.

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

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

2016-12-12 14:56 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:

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

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

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

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

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


>
>> Adami
>>
>
> Vlw Adami, muito obrigado. Vou realizar esses testes e volto a
> compartilhar com vocês o que tive que resultados.
>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-12-14 16:35 GMT-02:00 Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org>:

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

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

1- http://postgresapp.com/


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

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

2016-12-14 15:04 GMT-02:00 Leonardo Coleraus <leona...@fricke.com.br>:

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

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

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

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

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

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

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