Re: [pgbr-geral] Alinhamento

2011-11-30 Por tôpico Flavio Henrique Araque Gurgel
 Bom, na sua pergunta parecia justamente o que você queria.
 Poderia citar um exemplo de como você quer a saída?


 Da mesma forma do exemplo que passei na primeira mensagem, mas sem os +

Aqui estão duas saídas. Primeiro alinhadas:
postgres=# SELECT relname, relnamespace, reltype FROM pg_class LIMIT 10;
 relname | relnamespace | reltype
-+--+-
 pg_statistic|   11 |   10730
 pg_type |   11 |  71
 pg_attribute|   11 |  75
 pg_toast_1262   |   99 |   10951
 pg_toast_2604   |   99 |   10944
 pg_toast_2604_index |   99 |   0
 pg_toast_2606   |   99 |   10945
 pg_toast_2606_index |   99 |   0
 pg_constraint_conname_nsp_index |   11 |   0
 pg_am_name_index|   11 |   0
(10 registros)

Agora desalinhadas:

postgres=# \a
Formato de saída é unaligned.
postgres=# SELECT relname, relnamespace, reltype FROM pg_class LIMIT
10;
relname|relnamespace|reltype
pg_statistic|11|10730
pg_type|11|71
pg_attribute|11|75
pg_toast_1262|99|10951
pg_toast_2604|99|10944
pg_toast_2604_index|99|0
pg_toast_2606|99|10945
pg_toast_2606_index|99|0
pg_constraint_conname_nsp_index|11|0
pg_am_name_index|11|0
(10 registros)

O que você quer? Poderia ajustar uma das saídas acima pra nos dizer?
Ou melhor: o quê exatamente você quer fazer? Por que a saída do psql
faz tanta diferença? É só uma mostra em tela!

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


[pgbr-geral] Open-Source database marketshare : november 2011

2011-11-30 Por tôpico Rubens José Rodrigues
Vejam isto:

http://www.linkedin.com/groupItem?view=srchtype=discussedNewsgid=51776ite
m=81455389type=membertrk=eml-anet_dig-b_pd-ttl-cnut=35LHwnnTPrnl01

Rubens José Rodrigues

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


Re: [pgbr-geral] Alinhamento

2011-11-30 Por tôpico Emanuel Araújo

 O que você quer? Poderia ajustar uma das saídas acima pra nos dizer?
 Ou melhor: o quê exatamente você quer fazer? Por que a saída do psql
 faz tanta diferença? É só uma mostra em tela!


Versao do psql 9.0.2

bancodeteste=# SELECT parsing.fn_getsource('ftsl_rel_00l') ;
   fn_getsource
--
 /* * */ +
 /* ftsl_rel_00l - Step: 10   */ +
 /* * */ +
 DROP SEQUENCE IF EXISTS u_pkey_rel_produto_rel_001_seq; +
   DROP TABLE IF EXISTS tmp_relatorio;   +
   SELECT * FROM parsing.function_gera_rel_001(_CODMAQ_);+


Versao do psql 8.4.4

bancodeteste=# SELECT parsing.fn_getsource('ftsl_rel_00l') ;
   fn_getsource
--
 /* * */
 /* ftsl_rel_00l - Step: 10   */
 /* * */
 DROP SEQUENCE IF EXISTS u_pkey_rel_produto_rel_001_seq;
   DROP TABLE IF EXISTS tmp_relatorio;
   SELECT * FROM parsing.function_gera_rel_001(_CODMAQ_);


Estaá vendo a diferença?  Temos rotinas de exportação do resultado usando
\o, e depois dessa mudança, temos sempre que entrar no arquivo para
retirar esses + no final, porque eu jogo a saida para um arquivo e depois
rodo esse arquivo,m se não tiver uma forma de tirar essa formatação, tenho
que mudar o nosso processo aqui.  entendeu?

-- 
*Atenciosamente,

Emanuel Araújo*
http://eacshm.wordpress.com/
*
*
*Linux Certified
LPIC-1*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Alinhamento

2011-11-30 Por tôpico Flavio Henrique Araque Gurgel


 O que você quer? Poderia ajustar uma das saídas acima pra nos dizer?
 Ou melhor: o quê exatamente você quer fazer? Por que a saída do psql
 faz tanta diferença? É só uma mostra em tela!


 Versao do psql 9.0.2

 bancodeteste=# SELECT parsing.fn_getsource('ftsl_rel_00l') ;

fn_getsource
 --
  /* * */ +
  /* ftsl_rel_00l - Step: 10   */ +
  /* * */ +
  DROP SEQUENCE IF EXISTS u_pkey_rel_produto_rel_001_seq; +

DROP TABLE IF EXISTS tmp_relatorio;   +
SELECT * FROM parsing.function_gera_rel_001(_CODMAQ_);+


 Versao do psql 8.4.4

 bancodeteste=# SELECT parsing.fn_getsource('ftsl_rel_00l') ;

fn_getsource
 --
  /* * */
  /* ftsl_rel_00l - Step: 10   */
  /* * */
  DROP SEQUENCE IF EXISTS u_pkey_rel_produto_rel_001_seq;

DROP TABLE IF EXISTS tmp_relatorio;
SELECT * FROM parsing.function_gera_rel_001(_CODMAQ_);


 Estaá vendo a diferença?  Temos rotinas de exportação do resultado usando
 \o, e depois dessa mudança, temos sempre que entrar no arquivo para
 retirar esses + no final, porque eu jogo a saida para um arquivo e depois
 rodo esse arquivo,m se não tiver uma forma de tirar essa formatação, tenho
 que mudar o nosso processo aqui.  entendeu?


Agora esclareceu.
Qual o sistema operacional onde está rodando o psql?

Verifique as configurações do pset:
\pset recordsep
\pset fieldsep

Verifique se algum deles está com o sinal de + e troque pelo que você
precisa.
Depois você pode colocar no .psqlrc para ficar definitivo.
Verifique se você já não tem um .psqlrc com alguma configuração que está
sobrepondo os defaults no $HOME do usuário ou uma configuração para todo o
sistema operacional.

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


Re: [pgbr-geral] Fwd: select com distinct no proximo valor alterado

2011-11-30 Por tôpico Moisés P . Sena
2011/11/30 Bruno Silva bemanuel...@gmail.com

 Foi mal, nova versão:
 select data,mem from
(
   SELECT
row_number()
 OVER (ORDER BY data ROWS BETWEEN 1 PRECEDING AND 1
 FOLLOWING ) as linha,
first_value(mem)
 OVER ( ORDER BY data ROWS BETWEEN 1 PRECEDING AND 1
 FOLLOWING ) as anterior,*
   FROM memo order by data ) as janela
 WHERE anteriormem
 ORDER BY data;

data | mem
 -+--
  2011-11-21 15:22:00 | 1049
  2011-11-21 15:25:00 | 1052
  2011-11-21 15:26:00 | 1054
  2011-11-21 15:29:00 | 1065
  2011-11-21 15:30:00 | 1080
  2011-11-21 15:32:00 | 1073
  2011-11-21 15:33:00 | 1065
  2011-11-21 15:34:00 | 1049
 (8 rows)


Este funcionou beleza, exceto pelo fato de que ele nao retorna o primeiro
registro, no caso o de 2011-11-21 15:21:00.
Mas tirando isto, funcionou perfeitamente. Para o primeiro registro nao tem
muita importancia nao, mas, se voce souber um jeito de inclui-lo seria
legal =).

Meu problema foi resolvido com este script. Agora vou estudar como a funcao
OVER faz a magica aqui =).

Obrigado a todos voces pela ajuda!!

Abraços!!!

 Bruno E. A. Silva.


-- 
Moisés P. Sena
(Analista e desenvolvedor de sistemas WEB e mobile)
http://www.moisespsena.com
http://linux.moisespsena.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Open-Source database marketshare : november 2011

2011-11-30 Por tôpico Leandro Guimarães Faria Corce DUTRA
Le 2011-N-30  08h40, Rubens José Rodrigues a écrit :
 http://www.linkedin.com/groupItem?view=srchtype=discussedNewsgid=51776item=81455389type=membertrk=eml-anet_dig-b_pd-ttl-cnut=35LHwnnTPrnl01

A mesma informação não existe nalguma página aberta?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/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] Cancelamento de consulta em escravo (era: sem assunto)

2011-11-30 Por tôpico Flavio Henrique Araque Gurgel
 Boa tarde,

Boa tarde Tulio, favor inserir um assunto no email sempre que
perguntar algo na lista. Ajuda a manter a organização e buscas.

 Estou tentando executar uma consulta longa no servidor slave e está
 apresentado erro
 por entrar em conflito com a replicação...
 ERROR:  canceling statement due to conflict with recovery
 DETAIL:  User query might have needed to see row versions that must be
 removed.

 no log..
 2011-11-30 13:26:47 BRST [2299]: [5-1] user=usuario,db=atena LOG:  temporary
 file: path base/pgsql_tmp/pgsql_tmp2299.0, size 407044096
 2011-11-30 13:27:46 BRST [2299]: [6-1] user=usuario,db=atena ERROR:
 canceling statement due to conflict with recovery
 2011-11-30 13:27:46 BRST [2299]: [7-1] user=usuario,db=atena DETAIL:  User
 query might have needed to see row versions that must be removed.p

Isso pode realmente acontecer.

 Uso a versão 9.1... em Hot StandBy
 Isso é comum em outras versões?

A partir da 9.0, sim, é comum.

 Alguem ja passou por isso?

Sim. Isso acontece porque uma tupla necessária para a leitura da sua
consulta no escravo foi limpa pelo (auto)vacuum do mestre.
O mestre não tem como saber se uma página ainda é necessária para o
escravo, então, ele limpa cegamente e isso é totalmente replicado.

Você tem algumas alternativas:
1) No escravo, aumentar o valor de max_standby_streaming_delay. O
padrão é 30 segundos.
O PostgreSQL escravo faz então uma pausa na aplicação da replicação
até que sua consulta termine. Esse tempo pode ser aumentado. Você pode
colocar o valor 0 (zero) para que nenhuma consulta seja cancelada, mas
uma consulta muito demorada pode pausar a aplicação da replicação e os
dados lidos por outras consultas podem se tornar muito antigos. Se sua
aplicação tolera isso, sem problemas, por exemplo, se você só faz
consultas para alimentar um BI nesse escravo.

2) No mestre, configurar o valor de vacuum_defer_cleanup_age. Este
valor padrão é zero, ou seja, após uma tupla ser inútil para o
mestre, ela será limpa assim que o (auto)vacuum quiser. O valor aqui é
em transações. Você pode colocar um valor alto de transações (que você
precisa medir pra saber quantas) e então a rotina de limpeza espera
que esse número de transações passe para fazer a limpeza e replicá-la.
Nesta estratégia, haverá um aumento de consumode de espaço em disco
tanto do mestre como do escravo, pois páginas que poderia já estar
limpas ficarão disponíveis por mais tempo em disco. As consultas no
escravo terão então um tempo maior de validade de tuplas disponíveis e
mais dificilmente serão canceladas.

Espero que ajude, este tópico é muito interessante.
[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Cancelamento de consulta em escravo (era: sem assunto)

2011-11-30 Por tôpico Tulio Santos
Desculpe pelo sem assunto.. acabei me esquecendo..

Vou ficar com a opção 1, aumentando o delay para talvez 2min..
acredito que seja suficiente para o meu caso, e sem causar efeitos na segurança 
da replicação..

Obrigado
 
Att,
Tulio





 De: Flavio Henrique Araque Gurgel fha...@gmail.com
Para: Tulio Santos tuliogust...@yahoo.com.br; Comunidade PostgreSQL 
Brasileira pgbr-geral@listas.postgresql.org.br 
Enviadas: Quarta-feira, 30 de Novembro de 2011 17:01
Assunto: Cancelamento de consulta em escravo (era: sem assunto)
 
 Boa tarde,

Boa tarde Tulio, favor inserir um assunto no email sempre que
perguntar algo na lista. Ajuda a manter a organização e buscas.

 Estou tentando executar uma consulta longa no servidor slave e está
 apresentado erro
 por entrar em conflito com a replicação...
 ERROR:  canceling statement due to conflict with recovery
 DETAIL:  User query might have needed to see row versions that must be
 removed.

 no log..
 2011-11-30 13:26:47 BRST [2299]: [5-1] user=usuario,db=atena LOG:  temporary
 file: path base/pgsql_tmp/pgsql_tmp2299.0, size 407044096
 2011-11-30 13:27:46 BRST [2299]: [6-1] user=usuario,db=atena ERROR:
 canceling statement due to conflict with recovery
 2011-11-30 13:27:46 BRST [2299]: [7-1] user=usuario,db=atena DETAIL:  User
 query might have needed to see row versions that must be removed.p

Isso pode realmente acontecer.

 Uso a versão 9.1... em Hot StandBy
 Isso é comum em outras versões?

A partir da 9.0, sim, é comum.

 Alguem ja passou por isso?

Sim. Isso acontece porque uma tupla necessária para a leitura da sua
consulta no escravo foi limpa pelo (auto)vacuum do mestre.
O mestre não tem como saber se uma página ainda é necessária para o
escravo, então, ele limpa cegamente e isso é totalmente replicado.

Você tem algumas alternativas:
1) No escravo, aumentar o valor de max_standby_streaming_delay. O
padrão é 30 segundos.
O PostgreSQL escravo faz então uma pausa na aplicação da replicação
até que sua consulta termine. Esse tempo pode ser aumentado. Você pode
colocar o valor 0 (zero) para que nenhuma consulta seja cancelada, mas
uma consulta muito demorada pode pausar a aplicação da replicação e os
dados lidos por outras consultas podem se tornar muito antigos. Se sua
aplicação tolera isso, sem problemas, por exemplo, se você só faz
consultas para alimentar um BI nesse escravo.

2) No mestre, configurar o valor de vacuum_defer_cleanup_age. Este
valor padrão é zero, ou seja, após uma tupla ser inútil para o
mestre, ela será limpa assim que o (auto)vacuum quiser. O valor aqui é
em transações. Você pode colocar um valor alto de transações (que você
precisa medir pra saber quantas) e então a rotina de limpeza espera
que esse número de transações passe para fazer a limpeza e replicá-la.
Nesta estratégia, haverá um aumento de consumode de espaço em disco
tanto do mestre como do escravo, pois páginas que poderia já estar
limpas ficarão disponíveis por mais tempo em disco. As consultas no
escravo terão então um tempo maior de validade de tuplas disponíveis e
mais dificilmente serão canceladas.

Espero que ajude, este tópico é muito interessante.
[]s
Flavio Gurgel


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


Re: [pgbr-geral] Alinhamento

2011-11-30 Por tôpico Emanuel Araújo
Para voltar ao comportamento da versão 8.4, faça:


 \pset linestyle old-ascii



Obrigado Euler

-- 
*Atenciosamente,

Emanuel Araújo*
http://eacshm.wordpress.com/
*
*
*Linux Certified
LPIC-1*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Postgres 9.1 com Lazarus no Win7 64

2011-11-30 Por tôpico Marcelo Silva
Alguem usa essa combinação acima?
Estou tentando aqui e ele me pede as DLLs, mas estão todas lá no diretorio da 
aplicação
Interessante que essas mesmas DLLs funciona na combinação Delphi 7 + Zeos 7.1 + 
Postgres 9.1___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Obter Memoria usada pelo postgres

2011-11-30 Por tôpico Moisés P . Sena
Boa noite pessoal!

Uso linux debian 6 com PostgreSQL 9.0.

Preciso saber a quantidade de memoria utilizada pelo postgres em um
determinado BD. Isto é possivel?
E a memoria total usada pelo Postgres?

Abraços,

-- 
Moisés P. Sena
(Analista e desenvolvedor de sistemas WEB e mobile)
http://www.moisespsena.com
http://linux.moisespsena.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Postgres 9.1 com Lazarus no Win7 64

2011-11-30 Por tôpico Leandro DUTRA, Guimarães Faria Corcete
Le 2011-30-11 21h19, Marcelo Silva a écrit :
 Alguem usa essa combinação acima?
 Estou tentando aqui e ele me pede as DLLs, mas estão todas lá no
 diretorio da aplicação

‘Ele’ quem que pede?

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