Re: [pgbr-geral] Fw: Problemas na instalação da biblioteca PL/Perl
Dutra: Usei a uma distribuição padrão da Debian. Se faço a instalação do PostgreSQL a partir do repositório do SO, é instalada a versão 8.4 que vem sim com esta biblioteca disponível e funcionando. Porém esta versão não possui uma série de recusos que eu utilizo, nativamente do 9.0. Euler: executei o comando que você me solicitou e ele trouxe a seguinte resposta: pg_config --configure '--prefix=/opt/postgreSQL-9.0' '--with-python' '--with-perl' em uma seção do psql fiz também o comando: postgres=# CREATE LANGUAGE plperl; ERROR: could not access file "$libdir/plperl": Arquivo ou diretório não encontrado STATEMENT: CREATE LANGUAGE plperl; ERROR: could not access file "$libdir/plperl": Arquivo ou diretório não encontrado a instalação padrao pelo aptitude install apenas tem esta versão disponível: postgresql-plperl-8.4 Até então agradeço o empenho de vocês! Atenciosamente, Rieg - Original Message - From: "Guimarães Faria Corcete DUTRA, Leandro" To: "Comunidade PostgreSQL Brasileira" Sent: Monday, July 09, 2012 9:06 AM Subject: Re: [pgbr-geral] Fw: Problemas na instalação da biblioteca PL/Perl 2012/7/9 Rieg - JP : > /opt/postgreSQL/bin/createlang -h localhost -d nomedodatabase -U Que tal remover essa instalação e reinstalar dos repositórios do sistema operacional? ___ 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] Fw: Problemas na instalação da biblioteca PL/Perl
Funciona para instalar a versão 9.0 apartir do aptitude, mas houve um porém. PS.: Utilizei o repositório Backports. Quando instalo o postgresql-9.0-perl, existe uma dependência de uma biblioteca (libpq5 > 9.0) e esta por sua vez tem uma série de subdependências. Tais que eu encontrei apenas em repositórios unStable da Debian. o que deixou o SO bem instável, pois houve uma substituição de uma infinidade de bibliotecas. Por fim fui executar o createlang e acabou ocorrendo o mesmo erro, dizendo que não encontrou a biblioteca plperlu: "ERROR: could not access file "$libdir/plperl": Arquivo ou diretório não encontrado STATEMENT: CREATE EXTENSION "plperlu";" Até então agradeço. Rieg. - Original Message - From: "Flavio Henrique Araque Gurgel" To: Sent: Monday, July 09, 2012 3:55 PM Subject: Re: [pgbr-geral] Fw: Problemas na instalação da biblioteca PL/Perl On 09-07-2012 15:42, Guimarães Faria Corcete DUTRA, Leandro wrote: > Então use um /backport/, ou até mesmo experimente uma distribuição > mista, se não for o caso de rodar a /testing/. Eu já uso Wheezy (Testing) em minhas máquinas, mas nos clientes que rodam Debian Squeeze (Stable) recomendo o backports pra usar 9.0 ou 9.1 onde necessário: http://backports-master.debian.org/ []s Flavio Henrique A. Gurgel Consultor e Instrutor 4Linux Tel: +55-11-2125-4747 www.4linux.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] Instalação da versão 9.1
A mensagem é clara... Você está tentando usar os repositórios da Red Hat e você não tem o SO Registrado. Para utilizar os repositórios deles, você tem que registrar o SO, outra alternativa é utilizar um dos repositórios para Red Hat alternativos. Ou senão podes baixar o pacote para red hat e instalar manualmente conforme o Bruno Silva passou abaixo. - Original Message - From: Bruno Silva To: Comunidade PostgreSQL Brasileira Sent: Saturday, September 01, 2012 12:21 PM Subject: Re: [pgbr-geral] Instalação da versão 9.1 Você baixou os rpm? O comando e rpm -Uvh pacote Enviado pelo meu Nexus Em 01/09/2012 10:22, "Leandro" escreveu: Pessoal uma duvida para o pessoal que conhece linux bem. Estou instalando a versão 9.1 do postgresql baixei os rpm do site da comunidade mas ao instalar ocorre o seguinte: [root@mol postgres9]# yum install postgresql91-server-9.1.3-1PGDG.rhel5.x86_64.rpm --nogpgcheck Loaded plugins: rhnplugin, security This system is not registered with RHN. RHN support will be disabled. Excluding Packages in global exclude list Finished Setting up Install Process Examining postgresql91-server-9.1.3-1PGDG.rhel5.x86_64.rpm: postgresql91-server-9.1.3-1PGDG.rhel5.x86_64 Nothing to do e nada é instalado. Alguem tem alguma dica porque isso ocorre? ___ 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] Instalação da versão 9.1
Tem lá sim, Porém o sistema operacional não está registrado tanto que na mensagem que o Leandro colou está escrito bem claramente que o Red Hat nao foi registrado, com isso a Red Hat não disponibiliza o serviço de suporte nem o de download de pacotes adicional. Para o comando yum funcionar no RedHat é necessário registrar o Sistema operacional. [root@mol postgres9]# yum install postgresql91-server-9.1.3-1PGDG.rhel5.x86_64.rpm --nogpgcheck Loaded plugins: rhnplugin, security This system is not registered with RHN. RHN support will be disabled. Excluding Packages in global exclude list Finished Setting up Install Process Examining postgresql91-server-9.1.3-1PGDG.rhel5.x86_64.rpm: postgresql91-server-9.1.3-1PGDG.rhel5.x86_64 Nothing to do - Original Message - From: Marcelo Silva To: Comunidade PostgreSQL Brasileira Sent: Sunday, September 02, 2012 11:05 AM Subject: Re: [pgbr-geral] Instalação da versão 9.1 Nos repositorios da RedHat nao tem o postgres? No ubuntu basta digitar: sudo apt-get install postgresql-9.1 Não tem Yum no seu SO? Talvez esse link ajude http://www.vivaolinux.com.br/artigo/Instalando-o-PostgreSQL-no-Fedora Marcelo Silva From: Joao Paulo Rieg Sent: Saturday, September 01, 2012 3:35 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Instalação da versão 9.1 A mensagem é clara... Você está tentando usar os repositórios da Red Hat e você não tem o SO Registrado. Para utilizar os repositórios deles, você tem que registrar o SO, outra alternativa é utilizar um dos repositórios para Red Hat alternativos. Ou senão podes baixar o pacote para red hat e instalar manualmente conforme o Bruno Silva passou abaixo. - Original Message - From: Bruno Silva To: Comunidade PostgreSQL Brasileira Sent: Saturday, September 01, 2012 12:21 PM Subject: Re: [pgbr-geral] Instalação da versão 9.1 Você baixou os rpm? O comando e rpm -Uvh pacote Enviado pelo meu Nexus Em 01/09/2012 10:22, "Leandro" escreveu: Pessoal uma duvida para o pessoal que conhece linux bem. Estou instalando a versão 9.1 do postgresql baixei os rpm do site da comunidade mas ao instalar ocorre o seguinte: [root@mol postgres9]# yum install postgresql91-server-9.1.3-1PGDG.rhel5.x86_64.rpm --nogpgcheck Loaded plugins: rhnplugin, security This system is not registered with RHN. RHN support will be disabled. Excluding Packages in global exclude list Finished Setting up Install Process Examining postgresql91-server-9.1.3-1PGDG.rhel5.x86_64.rpm: postgresql91-server-9.1.3-1PGDG.rhel5.x86_64 Nothing to do e nada é instalado. Alguem tem alguma dica porque isso ocorre? ___ 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 ___ 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 da versão 9.1
Leandro. Verifique se no repositório de pacotes da PostgreSQL nao tem a versão de seu sistema operacional: http://yum.postgresql.org/repopackages.php Neste link vc vai encontrar pacotes de instalação do banco e de outras ferramentas. Eu acredito que se desabilitar os repositórios da RedHat e habilitar o repositório da PostgreSQL vai funcionar nesta versão de SO que você tem. Att. Rieg - Original Message - From: Glauco Torres To: Comunidade PostgreSQL Brasileira Sent: Monday, September 03, 2012 11:52 AM Subject: Re: [pgbr-geral] Instalação da versão 9.1 No dia 3 de Setembro de 2012 09:32, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/3 Marcelo Silva : > > Outra alternativa seria, aderir ao Ubuntu que não tem essas restrições, mas > também sei que não é tão simples migrar um server. Debian, que é mais estável & seguro também, além de ser a origem do Ubuntu e totalmente comunitário e livre (para uma determinada definição de livre…) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Bom dia , sempre faço instalações em Red Hat e CentOS e em todos os casos independente de qual for a distro, eu copio o link do [ 1 ] Postgres e utilzo o wget. ***Exemplo funcional Postgres 9.1.5 [glauco@glaucotorres ] # wget http://ftp.postgresql.org/pub/source/v9.1.5/postgresql-9.1.5.tar.gz Bom depois de finalizado o download é linux básico. [ 1 ] http://www.postgresql.org/ftp/source/ Att. Glauco Torres -- ___ 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] Replicar dados do Firebird para PostgreSQL
Se que os dois bancos ficarem online simultaneamente e você precisa eventualmente manipular alguma informação no firebird pode utilizar a ferramenta chamada DBILink que é instalada no PostgreSQL. Ela conecta em outros bancos através de um driver DBD. A partir dessa ferramenta, você consegue consultar, modificar, inserir e remover registros no outro banco através de comandos locais no PostgreSQL. Sua instalação é bem trabalhosa e em algumas situações se o tráfego de consultas for grande pode reduzir a performance. Fiz uma vez a instalação dessa ferramenta no PostgreSQL 8.4. Atualmente não sei como está a compatibilidade dela em versões mais atualizadas. Att. Rieg. - Original Message - From: Matheus de Oliveira To: Comunidade PostgreSQL Brasileira Sent: Wednesday, September 05, 2012 11:44 AM Subject: Re: [pgbr-geral] Replicar dados do Firebird para PostgreSQL 2012/9/5 Thiago Rodrigues Olá pessoal, Estou trabalhando em um projeto que necessito buscar informações no banco de dados de um ERP que utiliza Firebird e transferí-las para meu SGBD (PostgreSQL). O sistema que estou desenvolvendo irá coexistir com o ERP, assim, gostaria que quando fosse inserido um novo cliente no Firebird (exemplo) o registro fosse automaticamente replicado para uma tabela no PostgreSQL. Se precisa que seja realmente "online", você pode criar uma trigger no Firebird que chama uma função UDF (vai ter que usar C, C++ ou Delphi) para inserir o dado no PostgreSQL. Também já vi produtos comerciais que prometem isso (feito via triggers), vou ver se acho aqui. Também gostaria de realizar essa operação sem alterar nada no Firebird. Sem nem mesmo criar uma trigger? Só com verificação agendada... Alguém tem alguma idéia? Uma maneira grotesca seria criar um job no contrab para verificar a cada X minutos se houve alguma nova inserção e em caso positivo, replicar para o PostgreSQL. Se você não precisa que essa "replicação" seja instantânea, essa é uma boa solução. Procure por processos ETL, geralmente funciona assim. Ah, e o ideal é armazenar alterações feitas na tabela, uma espécie de tabela delta, para ter dados sobre deleções e atualizações também (via trigger novamente). -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.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] Encoding CaseInsensitive
Eu quando preciso deste tipo de pesquisa uso um select com conversão do case
sensitive da seguinte maneira:
SELECT * FROM tabela WHERE UPPER(campo) = UPPER('jOsE');
Dessa maneira vai trazer todas instancias de Jose independente do case
digitado pelo usuario ou do case cadastrado.
Att. Rieg
- Original Message -
From: "Flávio Alves Granato"
To: "Hélio Oliveira" ;
Sent: Tuesday, September 18, 2012 4:54 PM
Subject: Re: [pgbr-geral] Encoding CaseInsensitive
Hélio Oliveira writes:
> Boa tarde Colegas!
>
> Para que em uma pesquisa eu possa digitar "jose" e o postgreSQL me
> retornar
> JOSE, José JoSé... envim, não levar em consideração (maisculas/minusculas
> e
> a acentuação) como devo proceder?
Ai você terá que ir pro lado da busca textual.[1]
é um caminho a percorrer muito legal e muito interessante...
chega-se ao ponto de ir para a taxonomia das palavras, sei que sua
questão é procurar sem case sensitive, mas... hehehehe
[1] http://www.postgresql.org/docs/9.1/static/textsearch.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
Re: [pgbr-geral] RES: RES: Banco Postgres Multi Empresa
Se a aplicação realmente for 100% separada e nunca vai haver consulta em dados das duas empresas, pode-se criar bases separadas no mesmo cluster e cada empresa conecta em uma base. Se por ventura o sistema ter que ser multiempresa onde vai existir informações comuns entre elas, não vejo melhor opção que criar realmente um campo nas tabelas para você informar a que empresa o registro se refere. Att. Rieg - Original Message - From: "Rodrigo" To: "'Comunidade PostgreSQL Brasileira'" Sent: Thursday, September 20, 2012 4:18 PM Subject: [pgbr-geral] RES: RES: Banco Postgres Multi Empresa > Entao! O mais trabalhoso que seria colocar o campo codempresa em todas as > tabelas se tornaria o mais rápido? > > Rodrigo > > -Mensagem original- > De: pgbr-geral-boun...@listas.postgresql.org.br > [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Guimarães > Faria Corcete DUTRA, Leandro > Enviada em: quinta-feira, 20 de setembro de 2012 15:28 > Para: Comunidade PostgreSQL Brasileira > Assunto: Re: [pgbr-geral] RES: Banco Postgres Multi Empresa > > 2012/9/20 Rodrigo : >> E em relação os cruzamentos de informações serem complexas não tem tanto >> problema...pois o tempo que vou economizar com código compensará... > > A curto prazo, sim, mas a longo… > > >> e as consultas entre os schemas? Isso pode pessar o sistema? > > Não pessar nem pesar, mas pode ficar inviável fazer uma pesquisa sobre ‘n’ > tabelas… principalmente consultas ad hoc. > ___ > 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] Gravar e ler Bytea
Aqui em nosso sistema gravamos arquivos em banco através da aplicação por meio de conexão SQL. Eu tenho também outra aplicação PHP que grava fotos em banco e para a mesma funcionar corretamente, tive que alterar o parametro de configuração da seguinte maneira: bytea_output = 'escape'# hex, escape Att. Rieg - Original Message - From: Matheus de Oliveira To: Comunidade PostgreSQL Brasileira Sent: Tuesday, October 02, 2012 12:25 PM Subject: Re: [pgbr-geral] Gravar e ler Bytea 2012/10/2 Nelson Luiz Gonzaga Em 2 de outubro de 2012 09:19, Matheus de Oliveira escreveu: 2012/10/2 Nelson Luiz Gonzaga Ola lista, Tenho um EDM(GED) e agora estou separando o pg_largeobject em diversas tabelas divididas por tipo de documento para conseguir replicar com o slony. Fiz duas functions que simulam o lo_import e lo_export e esta rodando perfeitamente, porem utilizo o pg_largeobject e depois executo o unlink. So por preciosismo: Tem como gravar e ler diretamente nas tabelas, com o bytea, utilizando somente comandos sql? o ODBC emite erro "type lo does not exist;" Usando escapes você consegue. Valeu Matheus. Mas o Postgresql tem alguma funcao que transforma um arquivo em sequencia de escapes ou em hex? A minha ideia é usar comandos no servidor pra aliviar a maquina do usuario e a rede. Bom, se você já enviou o arquivo para o servidor você pode usar a função pg_read_binary_file [1]. E para ler um bytea em texto puro você pode usar a função decode [2]. PS: Acho que dá pra perceber as implicações de performance do uso de bytea desta maneira, certo? [1] http://www.postgresql.org/docs/9.2/static/functions-admin.html#FUNCTIONS-ADMIN-GENFILE-TABLE [2] http://www.postgresql.org/docs/9.2/static/functions-string.html#FUNCTIONS-STRING-OTHER Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres -- ___ 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] Acessar Oracle
Untitled DocumentTive este problema na instalação do DBI-Link quando fui fazer a instalação do mesmo no banco 9.0 ou superior. Como precisava da ferramenta apenas como camada intermediária de comunicação entre Oracle 10g e PostgreSQL 9.0, utilizei uma máquina virtualizada com o banco 8,4 instalado e com as ferramentas do DBI-Link, aí eu instalei os pacotes de conexão com o Oracle fornecidos por eles, e logo depois disso instalo o DBD-Oracle. Com isso ao vc fazer a chamada no banco que vai acessar o oracle esta mensagem não ocorreu mais. - Original Message - From: Abel Viera - Fundaçao Pio XII To: pgbr-geral@listas.postgresql.org.br Sent: Monday, October 22, 2012 11:25 AM Subject: [pgbr-geral] Acessar Oracle Bom Dia a Todos : Consegui em outra maquina acessar dados do Oracle , agora em outra máquina tento executar este mesmo codigo e ele me retorna erro "Não foi possivel localiza o ponto de entrada do procedimento OCIDBStartup na biblioteca de vinculo dinamico OCI.Dll" e tambem este erro install_driver(Oracle) failed: Can't load 'C:/Perl/lib/auto/DBD/Oracle/ l' for module DBD::Oracle: load_file:NÒo foi possÝvel encontrar o proce specificado at C:/Perl/lib/DynaLoader.pm line 191. at (eval 3) line 3. Compilation failed in require at (eval 3) line 3. Perhaps a required shared library or dll isn't installed where expected at ola.pl line 4. alguem poderia me ajudar Grato a todos ::: www.hcancerbarretos.com.br -- De acordo com a Politica de Seguranca da Informacao da Fundacao PIO XII, o emitente desta mensagem e plenamente responsavel por sua utilizacao e conteudo, que pode nao representar a opiniao da Fundacao PIO XII. Caso V. Sa. nao seja o destinatario ou a pessoa responsavel pela entrega desta mensagem, favor comunicar de imediato o remetente. -- ___ 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: Acessar Oracle
Untitled DocumentSegue abaixo os comandos que eu utilizei para instalação do DBD no Debian 6.0.5-i386 #dpkg -i oracle-instantclient-basic_10.2.0.3-2_i386.deb #dpkg -i oracle-instantclient-devel_10.2.0.3-2_i386.deb #dpkg -i oracle-instantclient11.2-basic_11.2.0.3.0-2_i386.deb #dpkg -i oracle-instantclient11.2-devel_11.2.0.3.0-2_i386.deb #aptitude install libdbd-oracle-perl Não esqueça que antes da instalação dos drivers da Oracle vc deve instalar o Driver do PostgreSQL (DBD-pg-2.7.2). Esse conjunto tem funcionado legal. Att. Rieg - Original Message - From: Abel Viera - Fundaçao Pio XII To: 'Comunidade PostgreSQL Brasileira' Sent: Monday, October 22, 2012 3:28 PM Subject: [pgbr-geral] RES: Acessar Oracle O Código esta perfeito, pq já funciona , mas como a maquina é outra, talvez estaria buscando em outro local .. Uma coisa é certa este DBD::Oracle dá um trabalho !! Alguem tem um luz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Conexao PostgreSQL via JDBC em dispositivos móveis
Bom dia! Estou desenvolvendo uma aplicação em Java, para Android 4.0, esta aplicação irá fazer transações no PostgreSQL 9.0, porém nao encontrei nenhum JDBC, para Android. Procurei em foruns e encontrei um JDBC modificado, cujo qual consegui fazer a conexão. Alguém da Comunidade já teve esta necessidade ou conhecem alguma outra ferramenta que seja mais apropriada para fazer a conexão com o PostgreSQLno Android? Atenciosamente, Rieg.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Conexao PostgreSQL via JDBC em dispositivos móveis
Em 26 de outubro de 2012 08:37, Joao Paulo Rieg escreveu: > Bom dia! > > Estou desenvolvendo uma aplicação em Java, para Android 4.0, esta > aplicação > irá fazer transações no PostgreSQL 9.0, porém nao encontrei nenhum JDBC, > para Android. > Procurei em foruns e encontrei um JDBC modificado, cujo qual consegui > fazer > a conexão. Alguém da Comunidade já teve esta necessidade ou conhecem > alguma > outra ferramenta que seja mais apropriada para fazer a conexão com o > PostgreSQLno Android? Não só para PostgreSQL, como para qualquer banco de dados, drivers de comunicação com bancos de dados JDBC/ODBC/ADO/Native foram criados para operar em redes locais (LAN) ou que possuam baixa latência e comunicação intermitente. Se você estiver conectado via rede celular (Edge/3G/HSPA/4G/etc) pode ocorrer a troca de APN ou antena, e a conexão do banco de dados seria cancelada e a transação perdida. Desde os remotos tempos do Palm OS/Windows CE realizar a conexão do dispositivo móvel com um SGDB não é recomendável, por isso existem poucas soluções disponíveis. O ideal é realizar a comunicação por transferência de arquivos ou algum outro tipo de serviço (Socket, RPC, WebService). -- TIAGO J. ADAMI http://www.adamiworks.com @tiadami Olá Tiago. Ja tenho uma aplicação que roda em Windows, e a mesma consiste no seguinte: Estou conectado à rede da empresa via wi-fi e faço todas consultas necessárias no SGBD. Caso a rede wi-fi não esteja disponível, alguns clientes optaram pelo uso de VPN, porém com uma velocidade de consulta bem mais baixo, mas como o fluxo de informações não é contínuo e nem em grande escala, funciona legal. O software funciona em modo offline, e faz as atualizações mediante a disponibilidade da conexão. Este mesmo sistema estou desenvolvendo para Tablets, porém o JDBC disponivel para download no site da PostgreSQL, não é compativel para o Android. Quanto à perda de conexão a aplicação será preparada para caso isto ocorra, porém, gostaria de saber se existe algum componente que a Comunidade recomendaria utilizar nesta situação. Atenciosamente, Rieg ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como usar o CRETE ROLE com password já criptografado?
Olá pessoal.. Tenho uma tabela de usuários onde armazeno o usuário e senha de acesso do sistema. A senha já está criptografada com MD5. Eu preciso replicar esses usuários para a tabela nativa de usuários do PostgreSQL através do comando create role e manter a mesma senha. Já tentei o comando abaixo, mas sem sucesso: Trigger Function: DECLARE v_senha varchar(); BEGIN v_senha := 'md5' || (new.usu_senha); execute 'CREATE ROLE ' || new.usu_usuario || ' NOINHERIT LOGIN UNENCRYPTED PASSWORD ' || quote_literal(v_senha) ; return new; END; Alguma sugestão? Obrigado, Renato Tenho uma trigger que está assim: CREATE OR REPLACE FUNCTION gravar_role() RETURNS trigger AS $BODY$ DECLARE SQL TEXT; BEGIN IF TG_OP = 'INSERT' THEN SQL = 'CREATE ROLE '||NEW.usuario||' LOGIN PASSWORD '||quote_literal(NEW.passwd)||' INHERIT; '; EXECUTE SQL; RETURN NEW; ELSEIF TG_OP = 'UPDATE' THEN SQL = 'ALTER ROLE '||NEW.usuario||' PASSWORD '||quote_literal(NEW.passwd)||'; '; EXECUTE SQL; RETURN NEW; ELSEIF TG_OP = 'DELETE' THEN SQL = 'DROP ROLE '||OLD.usuario||'; '; EXECUTE SQL; RETURN OLD; END IF; END; $BODY$ LANGUAGE plpgsql VOLATILE; CREATE TRIGGER gravar_role BEFORE INSERT OR UPDATE OR DELETE ON sis_user FOR EACH ROW EXECUTE PROCEDURE gravar_role(); A unica preocupação que tive que fazer na aplicação é de não permitir modificar o nome do usuario. Esta trigger modifica a senha e também remove a role caso seja removido na tabela. Att. Rieg___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como usar o CRETE ROLE com password já criptografado?
Correto Renato! A senha que envio não é criptografada, pois na tela de cadastro que fiz não criptografo a mesma. Na verdade, a tabela de usuarios que fiz é para fins de obter informações mais detalhadas do mesmo. O login do sistema nao faço pela tabela e sim pela role. se a role existe e o usuario digitar a senha correta, ele loga no banco e terá acesso as tabelas de acordo com as permissões concedidas à role. Neste caso o próprio banco vai administrar essa questão das permissões aos usuarios logados. Na questão de criptografia da senha,... o banco faz a criptografia automatica quando crio/modifico a role e também no login. Att. Rieg Olá João Paulo.. tudo bem? no meu caso, a senha já está criptografada em MD5.. se eu fizer como vc fez, eu penso que a senha será criptografada 2 vezes.. Nos eu caso NEW.passwd não esta criptografado né? ou seja.. é um clear password. correto? valeu! Renato Em 14 de novembro de 2012 16:06, Joao Paulo Rieg escreveu: Olá pessoal.. Tenho uma tabela de usuários onde armazeno o usuário e senha de acesso do sistema. A senha já está criptografada com MD5. Eu preciso replicar esses usuários para a tabela nativa de usuários do PostgreSQL através do comando create role e manter a mesma senha. Já tentei o comando abaixo, mas sem sucesso: Trigger Function: DECLARE v_senha varchar(); BEGIN v_senha := 'md5' || (new.usu_senha); execute 'CREATE ROLE ' || new.usu_usuario || ' NOINHERIT LOGIN UNENCRYPTED PASSWORD ' || quote_literal(v_senha) ; return new; END; Alguma sugestão? Obrigado, Renato Tenho uma trigger que está assim: CREATE OR REPLACE FUNCTION gravar_role() RETURNS trigger AS $BODY$ DECLARE SQL TEXT; BEGIN IF TG_OP = 'INSERT' THEN SQL = 'CREATE ROLE '||NEW.usuario||' LOGIN PASSWORD '||quote_literal(NEW.passwd)||' INHERIT; '; EXECUTE SQL; RETURN NEW; ELSEIF TG_OP = 'UPDATE' THEN SQL = 'ALTER ROLE '||NEW.usuario||' PASSWORD '||quote_literal(NEW.passwd)||'; '; EXECUTE SQL; RETURN NEW; ELSEIF TG_OP = 'DELETE' THEN SQL = 'DROP ROLE '||OLD.usuario||'; '; EXECUTE SQL; RETURN OLD; END IF; END; $BODY$ LANGUAGE plpgsql VOLATILE; CREATE TRIGGER gravar_role BEFORE INSERT OR UPDATE OR DELETE ON sis_user FOR EACH ROW EXECUTE PROCEDURE gravar_role(); A unica preocupação que tive que fazer na aplicação é de não permitir modificar o nome do usuario. Esta trigger modifica a senha e também remove a role caso seja removido na tabela. Att. Rieg ___ 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] Qual o menor impacto, varias bases de dados ou varios schemas?
On 16-11-2012 12:09, Toty Ypiranga wrote: > Estou desenvolvendo um sistema de biotecnologia, na qual usuários > poderão se cadastrar livremente (publico) e armazenar suas sequências > de DNA e usar o sistema para uma serie de tarefas como alinhar > sequencia calcular peso molecular do DNA e etc... Como estou usando > biosql (conjunto de schemas e funções para padronização de base de > dados genômicas) com postgres emergiu a duvida sobre qual cenário > teria um melhor desempenho. > Os dois cenários tem vantagens e desvantagens. A principal pergunta é: qual a quantidade de usuários você espera? > Cenário: 01 – uma base de dados para cada usurário; > > neste cenário o usuário se cadastra e o sistema cria uma base de dados > com o conjunto de tabelas do biosql; > Vantagens * isolamento total; * catálogo pequeno (um catálogo por BD). Desvantagens * número alto de BDs significa número alto de conexões. > > Cenário: 02 – uma base de dados única para o sistema e um schema para > cada usuário; > > neste cenário criaria uma trigger na tabela usuario e cada novo > usuario cadastrado a trigger criaria um novo schema com as tabelas e > funções do biosql colocando o nome do schema com o id do usuario. > Vantagens * compartilhamento de objetos comuns; * número baixo de conexões (se estiver utilizando pool). Desvantagens * isolamento parcial (GRANT/REVOKE para cada novo usuário ou objeto); * catálogo inchado (número alto de objetos em um mesmo BD). > Diante dos cenários expostos acima, qual teria o melhor desempenho, ou > tanto faz, pois daria na mesma. > A resposta mais sensata seria: cenário mesclado. Utilizar o cenário 2 até um número razoável (que você terá que descobrir) de usuários. O cenário 1 será utilizado para expansão (quando cenário 2 atingir o limite preestabelecido). Utilizando de teorias de sistemas, e seguindo a linha de raciocínio do Euler e da Monica, não seria muito mais apropriado criar a estrutura com um esquema, e nas tabelas fazer a distinção a que usuarios os registros pertencem? Desta forma você pode criar views com a clausula WHERE usuario=current_user e a mesma vai apresentar apenas as informações do usuario logado... Quanto ao volume de informações, acredito que se você tiver nesta estrutura, íncides bem elaborados, não vai fazer o sistema perder a eficiência. Tenho trabalhado com tabelas em um ERP com mais de um bilhão de registros e com performance superior ao esperado. Mas claro com indices bem elaborados de acordo com a necesidade. Caso a estrutura atingir o limite preestabelecido utilize-se do cenario 1 para expansão. Att. João Paulo Rieg ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Qual o menor impacto, varias bases de dados ou varios schemas?
Gostaria de agradecer a todos pelas contribuições e me desculpar pela demora na resposta, pois fiquei off-line neste feriado. Com relação a colocação do Joao Paulo Rieg “Utilizando de teorias de sistemas, e seguindo a linha de raciocínio do Euler e da Monica, não seria muito mais apropriado criar a estrutura com um esquema, e nas tabelas fazer a distinção a que usuarios os registros pertencem?” A estrutura de relacionamento do sistema seria relativamente simples. Eu poderia criar uma relação de um para muitos entre a tabela usuário e tabela dna e fazer um inner join simples para exibir apenas as sequências genéticas de determinado usuário. Mas essa solução esbarra na questão da privacidade. Pois posso ter um pesquisador da usp estudando o genoma de um mosquito transmissor de uma patologia qualquer e querer usar o sistema. Em paralelo posso ter um medico em um hospital em Brasília que está realizando um estudo de mutação genética e comparando amostras de dna de indivíduos diferentes. Ambos podem querer usar scripts em perl prontos para realização de tarefas de bioinformatica, ou, usar algum device para conectar no sistema como uma maquina de PCR (um método para a criação de múltiplas cópias de DNA) que entenda o padrão BioSQL, A ideia de utilizar o BioSQL é justamente manter compatibilidade com outras soluções. Logo a questão da privacidade torna-se muito importante. O maior grau de privacidade e o isolamento total criando uma base para cada usuário, mas como já foi mencionado pela Monica, isso aumentaria o custo de manutenção do sistema, além de uma enorme redundância de estruturas repetidas. A ideia de usar uma modelagem Multi-Tenant (Sugestão do Flavio) me agradou bastante. Poderia usa-la na forma de Shared Database, Separate Schemas (cenário 2) e como sugeriu o Euler migrar parar uma base de dados para cada usuário (cenário 1). Antes que eu me esqueça o sistema contará inicialmente com 100 usuários, podendo ter n usuários depois, apesar de não existirem tantos biólogos e médicos mundo afora posso facilmente ver meu sistema com 1000 usuários. E isso me leva a necessidade manter constante vigilância no servidor para quando o mesmo atingir 50% de sua carga alugue outro servidor e comece uma estrutura de High Availability and Load Balancing. Em 19 de novembro de 2012 01:33, Joao Paulo Rieg escreveu: > > > On 16-11-2012 12:09, Toty Ypiranga wrote: >> Estou desenvolvendo um sistema de biotecnologia, na qual usuários >> poderão se cadastrar livremente (publico) e armazenar suas sequências >> de DNA e usar o sistema para uma serie de tarefas como alinhar >> sequencia calcular peso molecular do DNA e etc... Como estou usando >> biosql (conjunto de schemas e funções para padronização de base de >> dados genômicas) com postgres emergiu a duvida sobre qual cenário >> teria um melhor desempenho. >> > Os dois cenários tem vantagens e desvantagens. A principal pergunta é: > qual > a > quantidade de usuários você espera? > >> Cenário: 01 – uma base de dados para cada usurário; >> >> neste cenário o usuário se cadastra e o sistema cria uma base de dados >> com o conjunto de tabelas do biosql; >> > Vantagens > > * isolamento total; > * catálogo pequeno (um catálogo por BD). > > Desvantagens > > * número alto de BDs significa número alto de conexões. > >> >> Cenário: 02 – uma base de dados única para o sistema e um schema para >> cada usuário; >> >> neste cenário criaria uma trigger na tabela usuario e cada novo >> usuario cadastrado a trigger criaria um novo schema com as tabelas e >> funções do biosql colocando o nome do schema com o id do usuario. >> > Vantagens > > * compartilhamento de objetos comuns; > * número baixo de conexões (se estiver utilizando pool). > > Desvantagens > > * isolamento parcial (GRANT/REVOKE para cada novo usuário ou objeto); > * catálogo inchado (número alto de objetos em um mesmo BD). > >> Diante dos cenários expostos acima, qual teria o melhor desempenho, ou >> tanto faz, pois daria na mesma. >> > A resposta mais sensata seria: cenário mesclado. Utilizar o cenário 2 até > um > número razoável (que você terá que descobrir) de usuários. O cenário 1 > será > utilizado para expansão (quando cenário 2 atingir o limite > preestabelecido). > > > > > Utilizando de teorias de sistemas, e seguindo a linha de raciocínio do > Euler > e da Monica, não seria muito mais apropriado criar a estrutura com um > esquema, e nas tabelas fazer a distinção a que usuarios os registros > pertencem? > Desta forma você pode criar views com a clausula WHERE > usuario=current_user > e a mesma vai apresentar apenas as informações do usuario logado... > Quanto ao volume de informações, acredito que se você tiver nesta
[pgbr-geral] Invalid Memory Alloc Request Size
Boa tarde. Eu estou com problemas em um database, que é mais ou menos assim: se eu faço um SELECT * FROM tabela sem a clausula WHERE o banco fica por dias para tentar exibir os dados sem sucesso. Se eu executo um Vacuum, reindex ou qualquer outra rotina um erro é apresentado na tela, bem como se eu executar o dump dessa tabela o erro também é apresentado. No log do banco tem esse erro: ERRO: invalid memory alloc request size 4294967293 O que eu percebi é que a tabela não tem muitos registros. seu tamanho é relativamente pequeno. mas no postgresql.conf o shared_buffers está configurado exatamente com 4GB Será que este problema está relacionado ao shared buffers? O servidor está com o Windows2008 Server RC2 x64 e o banco é a versão 9.0 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Invalid Memory Alloc Request Size
e repetir seu commando. 2012-11-19 15:40:14 BRT LOG: todos os processos servidor foram terminados; reinicializando 2012-11-19 15:40:24 BRT FATAL: bloco de memória compartilhada pré-existente ainda está em uso 2012-11-19 15:40:24 BRT DICA: Verifique se ainda há processos servidor antigos sendo executados, e termine-os. 2012-11-19 15:40:52 BRT LOG: sistema de banco de dados foi interrompido; última execução em 2012-11-19 15:38:31 BRT 2012-11-19 15:40:52 BRT LOG: sistema de banco de dados não foi desligado corretamente; recuperação automática está em andamento 2012-11-19 15:40:52 BRT LOG: redo inicia em 26/7F06D640 2012-11-19 15:40:52 BRT LOG: pageaddr 25/AD096000 inesperado no arquivo de log 38, segmento 127, deslocalemto 614400 2012-11-19 15:40:52 BRT LOG: redo pronto em 26/7F095B78 2012-11-19 15:40:52 BRT LOG: última transação efetivada foi em 2012-11-19 15:40:11.308-03 2012-11-19 15:40:52 BRT FATAL: o sistema de banco de dados está iniciando 2012-11-19 15:40:53 BRT LOG: sistema de banco de dados está pronto para aceitar conexões 2012-11-19 15:40:53 BRT LOG: inicializador do autovacuum foi iniciado Atenciosamente João Paulo Rieg. Só por desencargo de conciência, você realizou um memteste no servidor? Apenas para eliminar a possibilidade de memoria ram ruim. E aproveitando o memteste rodar um chkdisk também, apenas para descartar a possibilidade de badblock. Qual o retorno de um select count(*) ? Curioso seu caso, já passei pela experiência de ter um registro ruim e ao deletar conseguir fazer um select *, não sabemos se é relamete esse o problema. Em 19 de novembro de 2012 13:59, Joao Paulo Rieg escreveu: > Boa tarde. > > Eu estou com problemas em um database, que é mais ou menos assim: > > se eu faço um SELECT * FROM tabela sem a clausula WHERE o banco fica por > dias para tentar exibir os dados sem sucesso. > Se eu executo um Vacuum, reindex ou qualquer outra rotina um erro é > apresentado na tela, bem como se eu executar o dump dessa tabela o erro > também é apresentado. > > No log do banco tem esse erro: > ERRO: invalid memory alloc request size 4294967293 > > O que eu percebi é que a tabela não tem muitos registros. seu tamanho é > relativamente pequeno. mas no postgresql.conf o shared_buffers está > configurado exatamente com 4GB > > Será que este problema está relacionado ao shared buffers? > > O servidor está com o Windows2008 Server RC2 x64 e o banco é a versão 9.0 > > ___ > 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] Invalid Memory Alloc Request Size
Então Por acaso seu banco passou por uma queda de energia ou desligamento forçado (shutdown)? O autovacuum está conseguindo executar normalmente (vide pg_stat_user_tables e pg_stat_all_tables)? O servidor não foi desligado ma mais de meses já. --São pouquissimas as tabelas que tem uma data no autovacuum setando que o mesmo foi executado. Resultados: SELECT * FROM pg_stat_user_tables where relname = 'ind_03_03_02_02_a3' 24208;"senda";"ind_03_03_02_02_a3";1;90444;0;0;0;0;0;0;0;0;"";"";"";"" last vacuum, last autovacuum, last analyse e last autoanalyse estão nulos. no pg_stat_all_tables o resultado é o mesmo. Esqueci de avisar antes mas quando fui executar o vacuum pelo pgAdmin, dava a mensagem que tem delete e insert concorrente, só que o banco estava totalmente ocioso e não havia nenhuma conexao concorrente. Achei muito estranho essas mensagens. Opa, Em 19 de novembro de 2012 17:07, Joao Paulo Rieg escreveu: Eu fiz um SELECT count(*) FROM ind_03_03_02_02_a3 e a mesma me retornou a quantidade de registros (90444) O tamanho dos dados dessa tabela não passa de 6MB com os indices e outros objetos, chega nos 16MB. Quanto ao teste de memória eu já havia providenciado que fosse feito com o gestor de infra... bem provavel que será executado a noite. O que me aconteceu agora foi que pelo pgAdmin, eu Cliquei sobre a tabela e fui na guia manutenção. Selecionei um Vacuum e o serviço do banco de dados parou na hora. Agora qualquer comando de manutenção que eu executar, o banco para. no log do banco ficou o seguinte registro: 2012-11-19 15:40:12 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent insert in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent insert in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:12 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:13 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:13 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:13 BRT AVISO: concurrent insert in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:13 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:14 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:14 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:14 BRT AVISO: concurrent insert in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:14 BRT AVISO: concurrent delete in progress within table "ind_03_03_02_02_a3" 2012-11-19 15:40:14 BRT LOG: processo servidor (PID 3272) foi terminado pela exceção 0xC005 2012-11-19 15:40:14 BRT DICA: Veja o arquivo de cabeçalho C "ntstatus.h" para obter uma descrição do valor hexadecimal. 2012-11-19 15:40:14 BRT LOG: terminando quaisquer outros processos servidor ativos 2012-11-19 15:40:14 BRT AVISO: finalizando conexão por causa de uma queda de um outro processo servidor 2012-11-19 15:40:14 BRT DETALHE: O postmaster ordenou a esse processo servidor para cancelar a transação atual e sair, porque outro processo servidor saiu anormalmente e possivelmente corrompeu memória compartilhada. 2012-11-19 15:40:14 BRT DICA: Dentro de instantes você poderá conectar novamente ao banco de dados e repetir seu commando. 2012-11-19 15:40:14 BRT AVISO: finalizando conexão por causa de uma queda de um outro processo servidor 2012-11-19 15:40:14 BRT DETALHE: O postmaster ordenou a esse processo servidor para cancelar a transação atual e sair, porque outro processo servidor saiu anormalmente e possivelmente corrompeu memória compartilhada. 2012-11-19 15:40:14 BRT DICA: Dentro de instantes você poderá conectar novamente ao banco de dados e repetir seu commando. 2012-11-19 15:40:14 BRT CONTEXTO: função SQL "current_user_oid" comando 1 2012-11-19 15:40:14 BRT AVISO: finalizando conexão por causa de uma queda de um outro processo servidor 2012-11-19 15:40:14 BRT DETALHE: O postmaster ordenou a esse processo s
Re: [pgbr-geral] Invalid Memory Alloc Request Size
Em 19-11-2012 17:37, Joao Paulo Rieg escreveu: > Então > Por acaso seu banco passou por uma queda de energia ou desligamento > forçado (shutdown)? O autovacuum está conseguindo executar normalmente > (vide pg_stat_user_tables e pg_stat_all_tables)? > O servidor não foi desligado ma mais de meses já. > --São pouquissimas as tabelas que tem uma data no autovacuum setando que > o mesmo foi executado. > Resultados: > SELECT * FROM pg_stat_user_tables where relname = 'ind_03_03_02_02_a3' > 24208;"senda";"ind_03_03_02_02_a3";1;90444;0;0;0;0;0;0;0;0;"";"";"";"" > last vacuum, last autovacuum, last analyse e last autoanalyse estão nulos. > no pg_stat_all_tables o resultado é o mesmo. > Esqueci de avisar antes mas quando fui executar o vacuum pelo pgAdmin, > dava a mensagem que tem delete e insert concorrente, só que o banco > estava totalmente ocioso e não havia nenhuma conexao concorrente. > Achei muito estranho essas mensagens. Você falou que seu servidor é "9.0" e roda em Windows. Qual a versão *exata* do PostgreSQL e arquitetura? Existe um comportamento similar em 9.0.0 da EnterpriseDB em 32 bits em Windows e com índices GIN. Veja mais em (se entender inglês): http://archives.postgresql.org/pgsql-bugs/2010-09/msg00193.php Você por acaso está usando PostGIS? A definição do índice usado em sua consulta está correta? Verifique o valor do parâmetro autovacuum_vacuum_cost_delay e nos passe aqui por favor (além das outras perguntas acima e *sem top post* senão não respondo mais). []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos & Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS OK Flávio... Desculpe pelo Top Post A versão completa do PostgreSQL é: PostgreSQL 9.0.7, compiled by Visual C++ build 1500, 64-bit A Arquitetura do servidor é: Dell PowerEdge T410, Processador Xeon E5620, 2.4GHz, 16GB de memória, 4 HDs SAS 320GB sendo: 1 Array de RAID 1 para o SO, e outro Array de RAID 1 para o Cluster. O Array do Cluster está com 50% de utilização. Não utilizo o PostGis. Quanto aos índices, Eles foram criados de acordo com a necessidade das consultas, porém no estado em que a tabela se encontra, não consigo nem recriá-los. Se tento fazer o dump já da erro... os parâmetros: autovacuum_cost_delay = 20ms vacuum_cost_delay = 0 postei os dois parâmetros por garantia pois percebi que você colocou os dois prefixos la em cima... Att. Rieg ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Invalid Memory Alloc Request Size
Em 20-11-2012 08:45, Joao Paulo Rieg escreveu: > OK Flávio... > Desculpe pelo Top Post Tudo bem. Sempre pedimos isso, alguns entendem, outros não. Como dica, da próxima vez, responda também quotando a mensagem original (como estou fazendo aqui) que facilita MUITO. > A versão completa do PostgreSQL é: PostgreSQL 9.0.7, compiled by Visual > C++ > build 1500, 64-bit > A Arquitetura do servidor é: Dell PowerEdge T410, Processador Xeon E5620, > 2.4GHz, 16GB de memória, 4 HDs SAS 320GB sendo: 1 Array de RAID 1 para o > SO, > e outro Array de RAID 1 para o Cluster. O Array do Cluster está com 50% de > utilização. Você tem um bom servidor, bons discos até, pergunto: Você está usando Windows 32 bit? Não vi resposta ainda sobre isso. Qual a versão exata do Windows? --->Windows 2008 Server RC2 x64 bits Você tem uma máquina 64 bit e está usando PostgreSQL 32 bit. Recomendo usar PostgreSQL 64 bit também, desde que seu S.O. também seja. ---> O banco instalado é x64... Qual o valor do seu shared_buffers? ---> Estava com 2 GB, começou esse erro ai aumentamos para o 4GB onde o problema parou de acontecer por algumas semanas tornando a ocorrer novamente. Qual o valor de work_mem? ---> 15MB Se qualquer um deles for > 2 GiB você vai enfrentar o problema que está passando. ---> Mesmo se o SO e o Banco instalado for 64 bit? Atualize o PostgreSQL para 9.0.10 que é a versão corretiva mais recente pra eliminar bugs conhecidos. ---> Posso instalar ela por cima da atual? Pois com este problema não consigo fazer o dump da base. Performance (nada a ver com seu problema): separe um disco para o pg_xlog também, além do cluster. ---> Faremos isto. > Não utilizo o PostGis. Ok, então descarta o problema do link que citei. ---> Beleza... Eu estive olhando também. > Quanto aos índices, Eles foram criados de acordo com a necessidade das > consultas, porém no estado em que a tabela se encontra, não consigo nem > recriá-los. Se tento fazer o dump já da erro... Você não precisa fazer dump para recriar os índices, apenas faça REINDEX. Todavia, se você não consegue rodar COPY (o comando usado pelo pg_dump em backup comum) então REINDEX, talvez, não funcione. Como o erro é em COPY, o problema não são índices. ---> Exato... o comando: reindex ind_03_03_02_02_a3 se executado faz o banco dar um shutdown na hora. Da mesma forma que se eu executar um vacuum ind_03_03_02_02_a3. > os parâmetros: > autovacuum_cost_delay = 20ms > vacuum_cost_delay = 0 Default. Desencana pro seu erro. > postei os dois parâmetros por garantia pois percebi que você colocou os > dois > prefixos la em cima... De sua mensagem anterior (já que você não quotou, esqueceu): > Esqueci de avisar antes mas quando fui executar o vacuum pelo pgAdmin, > dava a mensagem que tem delete e insert concorrente, só que o banco > estava totalmente ocioso e não havia nenhuma conexao concorrente. > Achei muito estranho essas mensagens. Qual o resultado da consulta abaixo? SELECT * FROM pg_prepared_xacts; Pode haver um lock deixado por um 2PC. Locks assim resistem até restart do PostgreSQL. ---> nem uma linha retornada pela consulta. Até porque após este problema o banco reiniciou já. (Tentei fazer um vacuum e o banco parou) O único passo que eu não fiz foi atualizar para a versão 9.0.10. Preciso saber se acaso o cluster é compativel com essa nova versão do banco pois não consigo fazer o dump? atual: 9.0.7 para o 9.0.10 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Invalid Memory Alloc Request Size
- Original Message - From: "Flavio Henrique Araque Gurgel" To: Sent: Thursday, November 22, 2012 12:58 PM Subject: Re: [pgbr-geral] Invalid Memory Alloc Request Size Em 20-11-2012 13:33, Joao Paulo Rieg escreveu: (...) > Se qualquer um deles for> 2 GiB você vai enfrentar o problema que está > passando. > ---> Mesmo se o SO e o Banco instalado for 64 bit? Não. Eu me enganei, desculpe. > Atualize o PostgreSQL para 9.0.10 que é a versão corretiva mais recente > pra eliminar bugs conhecidos. > ---> Posso instalar ela por cima da atual? Pois com este problema não > consigo fazer o dump da base. O Jota já respondeu, sim, pode instalar em cima da atual. Tenha um backup dos arquivos de dados antes, claro. (...) >> Quanto aos índices, Eles foram criados de acordo com a necessidade das >> consultas, porém no estado em que a tabela se encontra, não consigo nem >> recriá-los. Se tento fazer o dump já da erro... > Você não precisa fazer dump para recriar os índices, apenas faça REINDEX. > Todavia, se você não consegue rodar COPY (o comando usado pelo pg_dump > em backup comum) então REINDEX, talvez, não funcione. > Como o erro é em COPY, o problema não são índices. > ---> Exato... o comando: reindex ind_03_03_02_02_a3 se executado faz o > banco > dar um shutdown na hora. Da mesma forma que se eu executar um vacuum > ind_03_03_02_02_a3. Me parece que você tem arquivo de tabela corrompido. O melhor jeito de resolver isso é restaurar um backup (se você tiver, espero que tenha). Caso não tenha, você tem algumas alternativas: 1a- exportar os dados da tabela para um arquivo texto usando SELECT e filtrando a(s) tupla(s) defeituosas, que você terá de descobrir. 1b- recriar a tabela e restaurar os dados. 2- conectar-se ao PostgreSQL em modo monousuário e tentar eliminar as páginas defeituosas da(s) tabela(s) envolvida(s). Não tenho fácil aqui agora nenhuma documentação sobre como fazer isso, mas existe, se puder dar uma pesquisada ou alguém na lista te ajudar. (...) > Qual o resultado da consulta abaixo? > SELECT * FROM pg_prepared_xacts; > Pode haver um lock deixado por um 2PC. Locks assim resistem até restart > do PostgreSQL. > ---> nem uma linha retornada pela consulta. Até porque após este problema > o > banco reiniciou já. (Tentei fazer um vacuum e o banco parou) Como eu disse, as transações preparadas sobrevivem reinício do servidor. Como você não tem nenhuma, ok. > O único passo que eu não fiz foi atualizar para a versão 9.0.10. Preciso > saber se acaso o cluster é compativel com essa nova versão do banco pois > não > consigo fazer o dump? > atual: 9.0.7 para o 9.0.10 Sim, tente, sem problemas. Pergunta extra: este seu banco de dados por acaso foi atualizado de versão anterior do PostgreSQL usando pg_upgrade? []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos & Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS Muito obrigado Flávio Pelas dicas. >>Me parece que você tem arquivo de tabela corrompido. >>O melhor jeito de resolver isso é restaurar um backup (se você tiver, >>espero que tenha). >>Caso não tenha, você tem algumas alternativas: >>1a- exportar os dados da tabela para um arquivo texto usando SELECT e >>filtrando a(s) tupla(s) defeituosas, que você terá de descobrir. >>1b- recriar a tabela e restaurar os dados. Resolvemos o problema criando outra tabela identica, e fomos incluindo os registros que estavam na original, exceto as tuplas defeituosas. Depois truncamos a tabela de origem, e colocamos de volta os registros recuperados de volta. O backup e todas as funções de manutenção tornaram a funcionar normalmente. Estamos fazendo também um levantamento da situação do hardware, pois desconfiamos que há falhas no HD. Até entã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] JPG error #53
> Pessoal estou usando a versão 9.2 do postgresql e esta acontecendo o > seguinte erro: > JPEG error #53 > > SO Windows 2008 server > Conexão ZeosLib 6.6.6 > O paramentro do postgresa byte_ > Alguem tem aluma solução... > ajuste o postgresql.conf bytea_output = 'escape' vai funcionar de certeza! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao realizar insercao de registros no postgres
>Galera me da uma luz >Estou desenvolvendo uma aplicacao e quando vou realizar uma insercao no >postgres >esta aparecendo a seguinte mensagem >Sequencia de Bytes é invalida para a codificacao "UTF8" >Estou comecando a trabalhar com Postgres agora. Se seu database foi criado em UTF8 (SHOW server_encoding ) e seu client encoding estiver em Latin 1 (SHOW client_encoding) você tem que fazer só um pequeno ajuste em seu componente de conexão setando os parametros compativeis: Eu uso o ZEOS para conexão, aí no properties coloco: 'codepage=LATIN1 client_encoding=LATIN1' no ODBC, tem tem um campo também pra escrever as propriedades, se colocar isso lá a conexao vai assumir esses parametros. o JDBC acredito que seja a mesma coisa. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao realizar insercao de registros no postgres
Seguindo a regra da lista Angelo No Top Post... leia lá no final! Em 5 de dezembro de 2012 14:06, Angelo Neto escreveu: Joao Paulo sua Ideia da encoding e codepage deu certo esta dando para inserir acentos e ç porem no meu grid ele aparece em um sinal diferente em anexo a print Poderia me dar essa força? Em 5 de dezembro de 2012 12:20, Joao Paulo Rieg escreveu: >Galera me da uma luz >Estou desenvolvendo uma aplicacao e quando vou realizar uma insercao no >postgres >esta aparecendo a seguinte mensagem >Sequencia de Bytes é invalida para a codificacao "UTF8" >Estou comecando a trabalhar com Postgres agora. Se seu database foi criado em UTF8 (SHOW server_encoding ) e seu client encoding estiver em Latin 1 (SHOW client_encoding) você tem que fazer só um pequeno ajuste em seu componente de conexão setando os parametros compativeis: Eu uso o ZEOS para conexão, aí no properties coloco: 'codepage=LATIN1 client_encoding=LATIN1' no ODBC, tem tem um campo também pra escrever as propriedades, se colocar isso lá a conexao vai assumir esses parametros. o JDBC acredito que seja a mesma coisa. ___ - Original Message - From: Angelo Neto To: Comunidade PostgreSQL Brasileira Sent: Wednesday, December 05, 2012 3:13 PM Subject: Re: [pgbr-geral] Erro ao realizar insercao de registros no postgres Joao Paulo sua Ideia da encoding e codepage deu certo esta dando para inserir acentos e ç porem no meu grid ele aparece em um sinal diferente em anexo a print Poderia me dar essa força? Link da Imagem com o Erro. http://i45.tinypic.com/33yqnfo.jpg Bom Dia Angelo... Teste então os dois parametros que passei acima setando em UTF8 No padrão eu utilizo latin1 mas em alguns poucos casos eu precisei utilizar nos dois o parametro = UTF8 Acredito que não vai mais ter problemas! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replace de chr(13)
- Original Message - From: "Marcelo Silva" To: "Comunidade PostgreSQL Brasileira" Sent: Friday, December 07, 2012 7:05 PM Subject: Re: [pgbr-geral] Replace de chr(13) Então Osvaldo, consegui da seguinte forma select repacle(campo, chr(13)||chr(10), ' ') from tabela Marcelo Silva -- Desenvolvedor Delphi, PHP Tel.: (11) 2962-7390 Cel.: (11) 5250-1407 - Tim Cel.: (11) 9693-4251 - Vivo -Mensagem Original- From: Osvaldo Kussama Sent: Friday, December 07, 2012 6:33 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Replace de chr(13) Em 07/12/12, Marcelo Silva escreveu: > Senhores, como vão tudo bem? Espero que sim... > > Seguinte, estou precisando dar uma replace em todas as quebras de linha em > um campo Text, mas não estou conseguindo > > Exemplo no PGAdmin3 executo: > > SELECT REPLACE(CAMPO, CHR(13), ‘’) AS TEXTO FROM TABELA > > Em um teste com * no lugar de espaço vejo que ele até substitue o chr(13) > mas a linha ainda continua com quebra > > Alguma dica? > > > Ambiente: > > Postgres 9.1 > Servidor Linux > Codepage UTF-8 > Cliente LATIN1 > Mas chr(13) é o caractere CR e creio que você queira trocar o chr(10) LF. Se, por acaso, seu texto foi gerado em ambiente Windows talvez você tenha que eliminar o par CR/LF. Osvaldo é muito mais garantido que seja feita desta forma: SELECT REPLACE(REPLACE(campo_tabela, CHR(13), ''),CHR(10),'') AS campo_tabela FROM tabela Por quê dois replaces? o CHR(10) equivale a quebra de linha quando utilizamos algumas aplicações que trabalham com texto puro. as vezes, temos aplicações que escreverm o CHR(13) para a quebra de linha. Esntão se faz os dois replaces. Da maneira acime feita (CHR(13)||CHR(10)) só vai remover se estiverem os dois concatenados. Tem uma opção bem mais prática de se remover caracteres: SELECT translate(campo_tabela,quote_literal(CHR(10)||CHR(13)),'') AS campo_tabela FROM tabela; o comando translate(campo_origem, string_procura, string_substituiçao) se não tiver o correspondente no segundo parametro, ele remove apenas o caractere. Att. Rieg ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
