Re: [pgbr-geral] Shell script Wal files

2007-10-30 Por tôpico Guilherme Augusto da Rocha Silva
Fiz o meu na semana passada... :D
Ainda está em testes pois tenho umas situações muito específicas aqui.
Mas, mais cedo ou mais tarde disponibilizo pra todos.
Abraços.

 From: Joao [EMAIL PROTECTED]
 Subject: [pgbr-geral] Shell script Wal files
 To: Comunidade PostgreSQL Brasileira
 pgbr-geral@listas.postgresql.org.br

 Pessoal ta ai um shell script que faz o seguinte!
 Cada vez que é executado realiza a copia fisica do banco de dados salva em
 uma pasta determinada, e comeca do zero o sistema de backup utilizando wal.
 Ele salva os wal files anteriores para caso de algum imprevisto movendo
 para uma pasta

 Coloque no cron!

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Seleção randômica

2007-10-30 Por tôpico Guilherme Augusto da Rocha Silva
Experimente:

SELECT * FROM pensamento ORDER BY RANDOM();

Abraço.


 Date: Tue, 30 Oct 2007 16:21:26 -0300
 From: Rudinei Dias [EMAIL PROTECTED]
 Subject: [pgbr-geral] Seleção randômica
 To: pgbr-geral@listas.postgresql.org.br

 Olá!

 No postgres há como fazer, via consulta sql, o retorno de um registro de
 forma randômica?
 Tenho uma tabela que armazena pensamentos de autores.
 A cada consulta que que o sql retorne uma e somente uma linha de forma
 aleatória.

 Valeu!

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] unificação de chaves estrangeiras

2007-10-19 Por tôpico Guilherme Augusto da Rocha Silva
Fernando,

só consegui resolver isto criando funções PLPGSQL e/ou rogramas (PHP) que 
comparam o conteúdo desejado e fazem um DE-PARA para depois unificar os 
registros. Se for só em uma tabela fica mais simples... o problema é quando 
outras tabelas referenciam as chaves da tabela que você está acertando... aí 
dá muito mais trabalho.

Abraço.

Em Sexta 19 Outubro 2007 14:26, [EMAIL PROTECTED] 
escreveu:
 Date: Fri, 19 Oct 2007 15:12:29 -0300
 From: Fernando de Oliveira [EMAIL PROTECTED]
 Subject: [pgbr-geral] unificação de chaves estrangeiras
 Pessoal,
 Tenho um cadastro base que é referenciado em diversas outras tabelas.
 Exemplo:
 codigo        Nome                               cpf
 ---
 1                                                11
 2                                                22
 3                                                11
 ---
 Observem  que o cadastro 1 e 3 se referem à mesma pessoa.
 Quero trocar em todos os locais que referenciam o cadastro 3 pelo cadastro
 1.
 Alguem tem uma sugestão de como fazer este procedimento?

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Ref: Privilégios de usuario.

2007-10-19 Por tôpico Guilherme Augusto da Rocha Silva
Não existem triggers de autonumeração a não ser que você as tenha criado.

Existem os SEQUENCES, que são usados em automatização de numeração.

Se for este o caso, seus sequences podem estar sem permissão de leitura 
(SELECT) e escrita (UPDATE) para o tal usuário que você criou.

Abraço.

Em Sexta 19 Outubro 2007 14:26, [EMAIL PROTECTED] 
escreveu:
 Date: Fri, 19 Oct 2007 15:14:18 -0300
 From: Paulo [EMAIL PROTECTED]
 Subject: [pgbr-geral] Ref: Privilégios de usuario.

 Olá Pessoal,

 Criei um usuario com GRANT ALL com todos os privilégios
 inclusive triggers.
 ocorre que quando tento incluir dados, este usuario nao consegue
 porque nao tem permissao de executar os triggers de autonumeração
 que criei para as tabelas. Se eu acesso como superusuario, obviamennte
 tudo funciona normal.

 Alguem tem alguma dica do que pode ser ?

 Obrigado.

 Paulo
 VisualP Sistemas.

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Diferença na estrutura de 2 bancos

2007-10-18 Por tôpico Guilherme Augusto da Rocha Silva
Olá,

procure por uma ferramenta chamada pgdiff nos projetos da PgFoundry 
(www.pgfoundry.org).

Ou, como disse o Pablo, use o comando diff comparando os arquivos com dados de 
cada banco. Os arquivos podem conter o SQL da estrutura (gerado com 
pg_dump -s) ou dados de estutura consultados diretamente no catálogo dos 
bancos.

Abraço.

 Date: Thu, 18 Oct 2007 08:08:15 -0300
 From:  Pablo Sánchez  [EMAIL PROTECTED]
 Subject: Re: [pgbr-geral] Diferença na estrutura de 2 bancos

 hummm

 Gerar o script sql e rodar um diff? :-P

 Em 18/10/07, sergio[EMAIL PROTECTED] escreveu:
  Bom Dia.
  Há alguma maneira prática para que eu compare 2 bancos e verifique quais
  os triggers, campos, tabelas, etc que há no primeiro e não se encontram
  no segundo?

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Digest pgbr-geral, volume 6, assunto 84

2007-08-28 Por tôpico Guilherme Augusto da Rocha Silva
Nelson, 

considere as dicas do outro colega que também respondeu.

Mas o negócio é o seguinte, se a CPU está quase IDLE e mesmo assim o processo 
parece agarrado mas ainda executando, grande chance de ser gargalo de I/O 
em disco.

 - quais as características do hardware?
   Sei que tem 2Gb de ram, o resto não sei muito.
Bom, 2G de RAM pode ajudar muito se seu servidor estiver usando mais o cache, 
o que não é o caso durante o procedimento de restore.

Outra coisa são os HDs. Que tipo? SCSI? SATA? IDE? Quantos? Qual modelo?
Use fdisk -l para ver os dispositivos de disco presentes no servidor.
Use hdparm -iv lista de dispositivos para ver o modelo e parâmetros de 
otimização cada um. Uma busca no Google pelos modelos encontrados pode ser de 
grande valia para descobrir se o gargalo está na velocidade dos HDs.

 - que tipo de sistemas de arquivo é utilizado?
ext3
Fuja! O sistema de arquivos EXT3 é muuuiiito lento!
Considere o uso de XFS. Estável, seguro e mantém a curva de performance 
trabalhando com arquivos muito grandes ou muito pequenos.

 - o servidor é dedicado para banco? no momento do restore o processamento é
 apenas deste ou há concorrência com outros bancos e aplicações? Sim,
 totalmente dedicado pro banco
OK

 - o servidor (S.O. e PostgreSQL) já recebeu tuning?
   Está padrão. Nenhum tuning.
Faça o tuning, pelo menos para este procedimento de restauração, caso não 
possa deixar definitivo no servidor. Vai ajudar muito. Considere os 
comentários dos colegas em outros posts sobre isso.

 - o arquivo que está sendo lido está no mesmo servidor do PostgreSQL ou
 está executando o pg_restore passando parâmetros para conexão via rede?
 Está no mesmo servidor. Acesso local
Ok, sem gargalo de rede.

 - já monitorou processamento e I/O com top, htop, ps, ou , vmstat,
 sar, iostat ou coisa similar, para ver onde está o gargalo? A máquina
 está idle. Quase não tem nada.
A CPU está IDLE, mas quanto de RAM está sendo usada? Fez uso de SWAP? Quanto 
de I/O em disco está sendo gerado? Use vmstat ou iostat para ver isto. 
O top não mostra isto claramente, a não ser pelos processos do 
gerenciamento de sistema de arquivos do kernel, que devem aparecer com mais 
frequencia que o normal.


Abraço.



Em Terça 28 Agosto 2007 17:41, [EMAIL PROTECTED] 
escreveu:
 Message: 5
 Date: Tue, 28 Aug 2007 15:07:36 -0300
 From: Nelson Cartaxo [EMAIL PROTECTED]
 Subject: [pgbr-geral] RES:  Digest pgbr-geral, volume 6, assunto 83
 To: Comunidade PostgreSQL Brasileira
 pgbr-geral@listas.postgresql.org.br
 Message-ID:
 [EMAIL PROTECTED]
 Content-Type: text/plain;   charset=iso-8859-1

 Respostas abaixo.
 Obrigado


  
  
 Atenciosamente,
 Nelson Cartaxo

 Dê mais informações, como:
 - quais as características do hardware?
   Sei que tem 2Gb de ram, o resto não sei muito.
 - que tipo de sistemas de arquivo é utilizado?
    ext3
 - o servidor é dedicado para banco? no momento do restore o processamento é
 apenas deste ou há concorrência com outros bancos e aplicações? Sim,
 totalmente dedicado pro banco
 - o servidor (S.O. e PostgreSQL) já recebeu tuning?
   Está padrão. Nenhum tuning.
 - o arquivo que está sendo lido está no mesmo servidor do PostgreSQL ou
 está executando o pg_restore passando parâmetros para conexão via rede?
 Está no mesmo servidor. Acesso local
 - já monitorou processamento e I/O com top, htop, ps, ou , vmstat,
 sar, iostat ou coisa similar, para ver onde está o gargalo? A máquina
 está idle. Quase não tem nada.

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Travamento de Banco e Vacuum

2007-08-20 Por tôpico Guilherme Augusto da Rocha Silva
O REINDEX pode ser executado como uma consulta SQL comum, pelo usuário dono da 
base de dados.

A documentação do PostgreSQL explica claramente como pode ser feito.
http://www.postgresql.org/docs/8.1/static/sql-reindex.html

Mas para adiantar seu lado o comando em SQL é:

REINDEX DATABASE sua_base;

Abraço.


Em Sexta 17 Agosto 2007 18:01, Vinicius escreveu:
 Minha instalacao do postgre 8.1 (windows) nao existe o arquivo reindexdb,,,
 assim nao consigo agendar uma tarefa para fazer o reindex.
 Alguem sabe como posso resolver isso, pois ja reinstalei o postgres em
 outra maquina e nao foi instalado este arquivo tbm.

 - Original Message -
 From: Guilherme Augusto da Rocha Silva [EMAIL PROTECTED]
 To: pgbr-geral@listas.postgresql.org.br
 Sent: Friday, August 17, 2007 2:18 PM
 Subject: Re: [pgbr-geral] Travamento de Banco e Vacuum


 Concordo em parte. O AUTOVACUUM, bem configurado e habilitado ajuda, e
 muito,
 o processo de manutenção e otimização, porém só ele não é o suficiente:

 É necessário o tratamento completo:
 - VACUUM e ANALYZE (autovacuum) 1 ou mais vezes por dia dependendo do seu
 volume de transações e da frequencia com que executa o REINDEX.
 - VACUUM FULL (autovacuum, ou na munheca), 1 vez ao dia no mínimo.
 - REINDEX {TABLE|DATABASE} (agendado no CRON ou??? ... na munheca), 1 vez
 ao
 dia, após o VACUUM FULL, não deixando mais de uma semana (catástrofe!!!)
 sem fazer.

 Abraço.


 Em Sexta 17 Agosto 2007 09:00, [EMAIL PROTECTED]

 escreveu:
  From: Marco A P D´Andrade [EMAIL PROTECTED]
  To: Comunidade PostgreSQL Brasileira
  pgbr-geral@listas.postgresql.org.br Sent: Thursday, August 16, 2007
  5:50 PM
  Subject: Re: [pgbr-geral] Travamento de Banco e Vacuum
 
 
  Sobre AUTOVACUUM:
 
  Por outro lado, se não me falha a memoria, se vc habilita o autovacuum,
  vc não precisa e não deve, rodar o vacuum manualmente, pois vale a
  ressalva de que um vacuum sem analyze não me pareceu ter o melhor
  resultado.

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Travamento de Banco e Vacuum

2007-08-17 Por tôpico Guilherme Augusto da Rocha Silva
MArco,

no tuning de memoria no SO, as variáveis são do kernel (pelo menos para o 
Linux, não faço idéia de como seja no Windows): shmall, shmmax, shmmni, sem.

Para ver o que são, e o que fazer com elas, favor executar o comando
man proc, e ler a documentação do PostgreSQL que indica quais valores podem 
ser colocados nestas variáveis.

http://www.postgresql.org/docs/8.1/static/kernel-resources.html#SYSVIPC
http://www.postgresql.org/docs/8.1/static/runtime-config-resource.html

Leituras adicionais obrigatórias para TUNING do PostgreSQL:
http://www.powerpostgresql.com/PerfList
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html

Em Quinta 16 Agosto 2007 18:09, [EMAIL PROTECTED] 
escreveu:
 Message: 3
 Date: Thu, 16 Aug 2007 17:50:31 -0300
 From: Marco A P D´Andrade [EMAIL PROTECTED]
 Subject: Re: [pgbr-geral] Travamento de Banco e Vacuum
 To: Comunidade PostgreSQL Brasileira
 pgbr-geral@listas.postgresql.org.br
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=iso-8859-1; format=flowed

 Senhores,

 Algo que me chamou a atenção, na questão do Rodrigo é a configuração de
 maintenance_work_mem [1].

 Considerando-se 2G de memoria, aumentar isto me parece uma boa opção !

 Sobre tunning de memoria:

 Quando ao shared_buffers, lembro que existem algums valores magicos
 que devidamente ajustados fazem o banco melhorar muito de performance, e
 claro, devem ser ajustados no SO antes, alguem recorda se esta é uma das
 variaveis ?

 Sobre AUTOVACUUM:

 Por outro lado, se não me falha a memoria, se vc habilita o autovacuum,
 vc não precisa e não deve, rodar o vacuum manualmente, pois vale a
 ressalva de que um vacuum sem analyze não me pareceu ter o melhor
 resultado.


 Sobre vacuum frequente:

     Vinicios,

     Vale a ressalva de que o vacuum tem por objetivo recuperar areas de
 banco liberadas, não traz beneficio para inserções !
     Talvez o que vc queira é um analyze, para melhorar estatísticas de
 índice...


     Estou retornando às origens, e à administração de banco de dados, e
 terei logo de cara uma plataforma no nivel que vc tem... (volume e
 hardware)... minha primeira preocupação é distribuição de tabelas em
 discos distintos, quando possível (vc citou discoS scsi). Outro ponto
 a trabalhar, antes de vacuum ou analyze são indices...



 [1] http://www.postgresql.org/docs/8.0/static/runtime-config.html

 Espero ter contribuido, pois estou retornando

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Travamento de Banco e Vacuum

2007-08-17 Por tôpico Guilherme Augusto da Rocha Silva
Desculpe, amigo, o que eu disse foi para não deixar de fazer REINDEX dos 
bancos de dados por mais de uma semana.

O ANALYZE deve ser executado sempre, para que o planejador e o otimizador de 
consultas possam propriciar uma performance melhor no acesso aos dados. 
Basicamente o que ele faz é uma amostragem dos dados em tabelas e índices 
análise da quantidade e frequência de valores.


Se não puder usar o AUTOVACUUM (que pode processar ANALYZE e VACUUM 
automaticamente e periodicamente), faça na mão (na sua aplicação ou via 
agendamento de tarefas).


*** Resuminho padrão para otimização das bases de dados (tabelas, índices):
- ANALYZE: sempre após inserções de muitos registros de dados (via INSERT ou 
COPY).
- VACUUM : sempre após alterações ou remoções de muitos registros de dados 
(viam UPDATE ou DELETE). Vai possibilitar o reaproveitamento dos blocos 
apagados e retardar a necessidade de um VACUUM FULL.
- VACUUM FULL:sempre após alterações ou remoções de muitos registros de dados 
(viam UPDATE ou DELETE) e sempre que se quiser eliminar definitivamente os 
blocos de apagados e liberar fisicamente o espaço em disco.
- REINDEX {TABLE|DATABASE}: como o VACUUM não limpa os blocos de dados 
removidos dos índices, o REINDEX é necessário sempre após alterações ou 
remoções de muitos registros de dados.

*** Como é meu procedimento padrão (nos + de 300 clientes com PostgreSQL)?
a) Deixo o autovacuum habilitado com intervalo de 60 minutos entre cada 
verificação e limites variando de 1 a 25000 registros inseridos para 
ANALYZE e 2 a 5 registros atualizados ou removidos para VACUUM.
Veja na documentação os detalhes de configuração.
b) Executo, na ordem abaixo, em cada uma das bases de dados existentes:
VACUUM FULL;
REINDEX DATABASE meu_banco;
ANALYZE;
antes do backup das mesmas, via CRON no servidor. Estes procedimentos podem 
ser realizados via programas vacuumdb e reindexdb. Veja a documentação os 
detalhes de funcionamento.


Abraços






Em Sexta 17 Agosto 2007 10:56, [EMAIL PROTECTED] 
escreveu:
 Message: 5
 Date: Fri, 17 Aug 2007 10:25:57 -0300
 From: Marco A P D´Andrade [EMAIL PROTECTED]
 Subject: Re: [pgbr-geral] Travamento de Banco e Vacuum
 To: Comunidade PostgreSQL Brasileira
 pgbr-geral@listas.postgresql.org.br
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=iso-8859-1; format=flowed

 Vinicius,

 O Guilherme foi bem mais preciso sobre as considerações sobre tunning.
 Sugiro avaliar os criterios dele.

 A ideia é o uso de uma analyze, para que a escolha de indices seja a
 mais adequada, de acordo com critérios gerenciados pelo BD.

 Observe que ele põe a ressalva de nao passar de 1 semana sem
 processamento de estatísticas de pesquisa.


 Guilherme,

 Como disse, estou retomando. Gostrei de sua abordagem, bem completa !
 Vou tomar por base em meus estudos :)


 Sds,
 Marco Antonio

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Poblema com float4

2007-08-16 Por tôpico Guilherme Augusto da Rocha Silva
Genuino,

para resolver o Poblema, recomendo a alteração de tipo de dado para NUMERIC.
Com NUMERIC, o valor sofre interferência.

Por exemplo, se a coluna precisa armazenar 3 dígitos à esquerda e 2 à direita 
do ponto (999.99), use NUMERIC(5,2).

Conceitualmente e na prática é mais coerente e seguro.

Abraço.

P.S.: poblema não existe, mas problema sim.


Em Quinta 16 Agosto 2007 09:00, [EMAIL PROTECTED] 
escreveu:
 Date: Wed, 15 Aug 2007 19:00:55 -0300 (ART)
 From: Genuino Teixeira [EMAIL PROTECTED]
 Subject: [pgbr-geral] Poblema com float4

 Olá,
   Estou usando a Version 8.0 do postgresql, e o encoding do banco de dados
 que eu uso é LATIN1. Em uma tabela tenho um campo float4 e quando insiro um
 dado do tipo 8.55 o banco arredonda para 8.6. 
   Alguém saberia como contornar este problema? Quando insiro 8.55 o valor
 deve permacer 8.55 e não ir para 8.6. 
   Vlw.



-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
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 entre datas

2007-08-16 Por tôpico Guilherme Augusto da Rocha Silva
Lourenço,

não sei se reparou, mas sua mensagem veio em um anexo que foi removido. 
Procure enviar sempre em texto simples, sem formatação e sem anexos. Assim 
todos da lista serão beneficiados e inclusive você.

Abraço.

Em Quinta 16 Agosto 2007 09:00, [EMAIL PROTECTED] 
escreveu:
 Message: 4
 Date: Tue, 14 Aug 2007 17:29:15 +0300
 From: Lourenco Bueno    [EMAIL PROTECTED]
 Subject: [pgbr-geral] Dúvida entre datas
 To: pgbr-geral@listas.postgresql.org.br
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=iso-8859-1

 Um anexo em HTML foi limpo...
 URL:
 http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20070814/4
1641dde/attachment-0001.htm

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Travamento de Banco e Vacuum

2007-08-16 Por tôpico Guilherme Augusto da Rocha Silva
 banco nao responde, da
 impressão que o banco trava ou pelo menos nao responde, se tento conectar
 fica parado esperando, nao da erro de conexao e nem timeout. Nao consigo
 dar shutdown no banco e nem dar kill nos processos do postmaster, a unica
 forma é reiniciando todo o servidor. Parece que ocorre um lock (ou
 deadlock) interno, o banco fica idle e nao responde.

 Os parametros do postgresql.conf que estou utilizando fora do default que
 estou utilizando sao:

 shared_buffers = 65536
 work_mem = 8192
 maintenance_work_mem = 16384

 fsync = false

 redirect_stderr = true
 client_min_messages = log
 log_destination = 'stderr'
 log_directory = 'pg_log'
 log_min_messages = log
 log_min_error_statement = info
 log_connections = true
 log_disconnections = true
 log_duration = true
 log_line_prefix = '%t %u %r'

 stats_start_collector = true
 stats_row_level = true

 Alguem passou por alguma situação semelhante? Procurei pela internet este
 caso, porem sem sucesso.

 Obrigado...

 Abraço a todos...

 Rodrigo

 -- Próxima Parte --
 Um anexo em HTML foi limpo...
 URL:
 http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20070816/8
7a0d0b2/attachment-0001.htm

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Funcao Verificador de Cpf e Cnpj

2007-08-03 Por tôpico Guilherme Augusto da Rocha Silva
Charles, esta função está disponível no artigo Stored procedures, triggers, 
functions..., do Juliano Ignácio, no site www.imasters.com.br.

O link para o artigo da função é:
http://www.imasters.com.br/artigo/1308/postgresql/stored_procedures_triggers_functions/

É escrita em PL/PGSQL e vai te ajudar no que precisa.
Testei aqui e funcionou bem.

Abraço.


Em Sexta 03 Agosto 2007 17:22, [EMAIL PROTECTED] 
escreveu:
 Message: 1
 Date: Fri, 3 Aug 2007 16:32:49 -0300
 From: Roberto Baselio Lopes [EMAIL PROTECTED]
 Subject: Re: [pgbr-geral] Funcao Verificador de Cpf e Cnpj
 To: Comunidade PostgreSQL Brasileira
 pgbr-geral@listas.postgresql.org.br
 Message-ID:
 [EMAIL PROTECTED]
 Content-Type: text/plain; charset=utf-8

 eu tenho classes em java, serve?

 Em 03/08/07, Charles - FuturoVirtual [EMAIL PROTECTED] escreveu:
  Pessoal, voces nao teriam uma funcao em plpgsql para verificação de cpf
  e cnpj? para não ter que reinventar a roda.
 
  Charles
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Gerar arquivo txt

2007-07-19 Por tôpico Guilherme Augusto da Rocha Silva
Use 'COPY TO':
   COPY dbuser TO 'saida.txt' CSV;


Veja na ajuda do psql (\h COPY) o que pode fazer:

Sintaxe:
COPY nome_tabela [ ( coluna [, ...] ) ]
TO { 'arquivo' | STDOUT }
[ [ WITH ]
  [ BINARY ]
  [ HEADER ]
  [ OIDS ]
  [ DELIMITER [ AS ] 'delimitador' ]
  [ NULL [ AS ] 'cadeia nula' ] ]
  [ CSV [ HEADER ]
[ QUOTE [ AS ] 'separador' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE QUOTE coluna [, ...] ]

Abraço.



Em Quinta 19 Julho 2007 10:17, [EMAIL PROTECTED] 
escreveu:
   Em 19/07/07, Livia [EMAIL PROTECTED] escreveu:
     Bom dia pessoal,
     alguém poderia me dar uma dica de como faço para gerar um arquivo TXT a
 partir do resultado de um select?

     Não sei se no postgres funciona assim, mas estou fazendo dessa maneira:

           SELECT * INTO OUTFILE ''saida.txt'' FROM dbuser;

           e está dando o seguinte erro:

           failed : ERROR: syntax error at or near '' at character 23  


     Alguém tem alguma dica?
     Agradeço.

-- 

/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados

Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Re:Re:Re:Re: Elefante - Ferramenta para monitoramento em português-BR

2007-06-05 Por tôpico Guilherme Augusto da Rocha Silva
Oi Coutinho,

muito obrigado pelo retorno!

Tem umas coisas que eu não consigo reproduzir aqui no meu ambiente de 
desenvolvimento, tipo PHP5 e PG 8.2... que é o seu caso.

Vou fazer primeiro as coisas que o Fernando Ike passou, para facilitar pra 
todos a instalação e configuração. Com isto pronto, também ficará claro o 
escopo do sistema e definido o rumo do desenvolvimento de novas 
funcionalidades.

A partir daí, será possível focar em compatibilização com versões mais atuais 
do PHP e PG... e aceitarei de bom grado qualquer ajuda para desenvolver o que 
for necessário. :D

Grande abraço!
:D





Em Ter 05 Jun 2007 12:19, Nabucodonosor Coutinho Costa escreveu:
 após comentar no codigo algumas variaveis re-declaradas, dar acesso trust
 ia localhost ao usuario postgres e testar a conexao sem senha no php e
 alterar as variaveis no postgresql.conf ficou quase funcionando.

 não da erro nenhum, mas diz que meu postmaster esta parado

 meu ambiente

 ubuntu feisty
 kernel 2.6
 apache 2
 php 5
 postgresql 8.2


  - Linux, distro Debian Sarge (3.x)
  - kernel 2.6.x
  - Apache 2.x
  - PHP 4.3.x
  - PostgreSQL 8.1.x.


 Nabucodonosor Coutinho Costa
 Desenvolvedor de Bugs

-- 


/*
Administração de Dados e Bancos de Dados
Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


[pgbr-geral] Re: Digest pgbr-geral, volume 5, assunto 11

2007-06-04 Por tôpico Guilherme Augusto da Rocha Silva
Olá.

Fernando, muito obrigado pelo retorno.

Conforme você indicou (obrigado mesmo!), vou providenciar para o próximo 
release:
a) Elaboração de textos para os arquivos:
- LICENSE
- README
- INSTALL
- FAQ
- TODO
b) Codificação/documentação em pt-BR.

   Olá.
Parabéns pela iniciativa.
   Análise rápida, coloca no seu TODO. ;)
Ok. O TODO também será providenciado.

 1 - Tua ferramenta não tem lugar nenhum dizendo qual a licença dele.
 (GPL, BSD, LGPL, etc.)
É BSD. Será contemplado no próximo release.

 2 - Tua ferramenta não tem um Readme ou Leiame com instruções básicas
 de instalação.
Ok. Será contemplado no próximo release.

 3 - Inglês/Português: Se sua aplicação estiver em português e voltada
 para pessoas desse idioma não tem necessidade de ter algo escrito ou
 documentado em inglês no código. Caso for o contrário, em inglês,
 altere as variáveis para este idioma como também os comentários, isso
 inclusive ajudará a ter mais pessoas usando e contribuindo.
Concordo... falha minha... confusão de correria...
Queria desenvolver algo para a comunidade internacional.
Depois vi que a prioridade deveria ser a comunidade brasileira. Aí mudei o 
rumo mas não mudei os fontes... vacilei :)

 4 - Uma parte dessas funcionalidades já está contemplado no phppgadmin?
 Se não, poderia dar uma mão para o pessoal. Que acha? =)

Bom, quanto ao PgAdminIII, sim, parte está no mesmo, mas o que eu queria é 
compartilhar um facilitador usado para o meu trabalho. Como aqui 
desenvolvemos sistemas corporativos em ambiente web (Linux + Apache + PHP + 
PostgreSQL), achei mais confortável desenvolver seguindo esta linha... tem 
o phppggadmin, na web, mas eu queria algo mais específico, onde todas estas 
ferramentas são bem carentes:
- monitoramento de recursos, 
- monitoramento de processos,
- estatísticas de bases de dados e suas estruturas,
- análise e dicas de configuração, de acordo com o comportamento de uso do 
servidor.

Enfim, o que eu quis focar mais é em monitoramento, necessidade de DBAs e 
administradores de sistemas. Para administrar bancos de dados eu uso e 
recomendo PgAdminIII, phppgadmin, e psql (que eu uso mais do que os outros).

Bom,é isto. Espero que outras pessoas também avaliem e mandem suas dicas.

Fernando, novamente, muito obrigado pela atenção e dicas extremamente úteis.

Abraço a todos.

-- 


/*
Administração de Dados e Bancos de Dados
Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral