Re: [pgbr-geral] Travamento de tabela
Em 05-07-2012 18:20, Aldrey Galindo escreveu: Criei um novo banco a partir do Backup de antiga. Depois tentei renomear o banco antigo e recebi a seguinte mensagem: --- mensagem --- LOG: statement: ALTER DATABASE bd001 RENAME TO bd001_ruim; ERROR: database bd001 is being accessed by other users DETAIL: There are 1 other session(s) and 1 prepared transaction(s) using the database. --- fim --- Isso *não* é um problema. Deve ser você mesmo acessando esse banco de dados. Conecte-se a outro banco (postgres por exemplo) e tente refazer a operação. Eu tô lendo essa thread e tá um blablabla terrível. Até agora não entendi: - o que você realmente *percebeu* de problema; até o momento só vi que você viu um lock, coisa absollutamente *normal* no PostgreSQL; - versão do PostgreSQL; - versão e arquitetura do S.O. Ajude-nos a ajudá-lo. []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
Re: [pgbr-geral] RES: PgAdmin no Win7
Em 05-07-2012 17:32, Anselmo Silva escreveu: Muito estranho, essa máquina não está comprometida? Uso Pg 9.0.7 normal. veja essas dicas: http://pcsupport.about.com/od/findbyerrormessage/a/msvcr90-dll-not-found-missing-error.htm Há condições de usar o postgres 32bits só para testar? Estou entendendo errado ou a discussão sobre PgAdmin virou questão de versão do PostgreSQL? Uma coisa não tem nada a ver com a outra: para usar o PgAdmin no Windows não há dependência da versão do PostgreSQL ao qual se está conectando. Atenham-se à solução do PgAdmin. O link aponta uma possível solução, que *não* tem a ver com a versão do PostgreSQL. []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
Re: [pgbr-geral] RES: PgAdmin no Win7
OK Flávio, é que até o momento não há nenhum indício, conforme outras pessoas acima citaram que usam no mesmo cenário, de problema específico com o PgAdmin. Isso não quer dizer que acho que o problema seja do Postgres, é um chute meu. Desculpa se os tirei do foco. Em 6 de julho de 2012 08:54, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Em 05-07-2012 17:32, Anselmo Silva escreveu: Muito estranho, essa máquina não está comprometida? Uso Pg 9.0.7 normal. veja essas dicas: http://pcsupport.about.com/od/findbyerrormessage/a/msvcr90-dll-not-found-missing-error.htm Há condições de usar o postgres 32bits só para testar? Estou entendendo errado ou a discussão sobre PgAdmin virou questão de versão do PostgreSQL? Uma coisa não tem nada a ver com a outra: para usar o PgAdmin no Windows não há dependência da versão do PostgreSQL ao qual se está conectando. Atenham-se à solução do PgAdmin. O link aponta uma possível solução, que *não* tem a ver com a versão do PostgreSQL. []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 -- Anselmo M. Silva ___ 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: PgAdmin no Win7
OK Flávio, é que até o momento não há nenhum indício, conforme outras pessoas acima citaram que usam no mesmo cenário, de problema específico com o PgAdmin. Isso não quer dizer que acho que o problema seja do Postgres, é um chute meu. E conexão via psql, vai normal? -- Matheus de Oliveira ___ 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 tabela
Flavio, O problema que me referi foi ao fato de que por algum motivo desconhecido para mim ele ficou com essa sessão travada. Não sei se foi devido ao restart do banco (não apresentou erros). Antes de fazer um backup de tudo e criar um novo banco, eu não sabia o que tinha ocorrido, pois não teve nenhuma mensagem de erro ou aviso. Pensei que era apenas algo em 1 tabela, mais acabou sendo no banco. Tentei apagar a tabela e recriar ela, apenas ela não fazia nada, ficava parado. Se quando tentei apagar ela, o banco tivesse informado dessa dessão do 'prepared transaction', aí sim o tempo de solução teria sido menor. Versão: 8.4.5 (ainda não atualizado para a 9.1) SO: RedHat 5 - 64 bits Desculpe pela sujeira na thread, não foi minha intenção. Em 6 de julho de 2012 08:51, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Em 05-07-2012 18:20, Aldrey Galindo escreveu: Criei um novo banco a partir do Backup de antiga. Depois tentei renomear o banco antigo e recebi a seguinte mensagem: --- mensagem --- LOG: statement: ALTER DATABASE bd001 RENAME TO bd001_ruim; ERROR: database bd001 is being accessed by other users DETAIL: There are 1 other session(s) and 1 prepared transaction(s) using the database. --- fim --- Isso *não* é um problema. Deve ser você mesmo acessando esse banco de dados. Conecte-se a outro banco (postgres por exemplo) e tente refazer a operação. Eu tô lendo essa thread e tá um blablabla terrível. Até agora não entendi: - o que você realmente *percebeu* de problema; até o momento só vi que você viu um lock, coisa absollutamente *normal* no PostgreSQL; - versão do PostgreSQL; - versão e arquitetura do S.O. Ajude-nos a ajudá-lo. []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
[pgbr-geral] Comunicação com Banco de dados lenta
Bom dia, Tenho uma aplicação java, mais precisamente um ERP, rodando PostgreSQL 9.1 em um Linux 64 bits. Agora nos surgiu a necessidade de ligar com um outro ponto, e esse só pode ser via link de rádio. O problema é que um processo local demora em torno de 10 segundos, já nesse link está demorando em torno de 30 a 40seg, o ping entre essas redes está entre 10 ms a 15 ms, Existe algo que possa melhorar direto no banco? Obrigado a todos que puderem ajudar -- Ats. Lucas de Lima ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PgAdmin no Win7
2012/7/5 Saulo Morais Lara sa...@abilityonline.com.br: Estou tendo problemas com o PgAdmin, tanto na versão 1.12.3 quanto na 1.14.3. Quando acesso o banco e clico em SQl Queries o PgAdmin para de funcionar. Está parecendo com o bug do arquivo de histórico de consultas. Ele foi corrigido na versão 1.12.3, você chegou a utilizar uma versão anterior? Tente renomear/excluir o arquivo pgadmin_histoqueries.xml presente no diretório %APPDATA%\postgresql\ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] REF. Lustagem Semanal.
Ola Pessoal, Tenho a seguinte sentença: select data,nome,valor from entradas where data between '20120601' and '20120630' order by data Preciso listar os dados a partir da data inicial e final, separada por semana. Ex: O mes de Junho tem 5 semanas: 1a) do dia 01 a 02 2a) do dia 03 a 09 3a) do dia 10 a 16 4a) do dia 17 a 23 5a) do dia 24 a 30 Preciso que o resultado seja o seguinte: Semana 01 2012-06-01;ANDRÉ ;200.00 2012-06-01;LUCIO ;175.00 2012-06-03;CELINA ;609.00 Semana 02 2012-06-04;CÉSAR ;570.00 2012-06-04;VOLNEI ;350.00 2012-06-05;AGNALDO ;190.00 2012-06-10;CARLOS ;300.00 2012-06-11;ELIEZER ;500.00 Semana 03 2012-06-21;ERIVAM ;85.00 2012-06-22;ADEMAR ;198.00 Alguem tem alguma dica ??? Obrigado. Paulo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
On 06-07-2012 09:32, Lucas de Lima wrote: Agora nos surgiu a necessidade de ligar com um outro ponto, e esse só pode ser via link de rádio. O problema é que um processo local demora em torno de 10 segundos, já nesse link está demorando em torno de 30 a 40seg, o ping entre essas redes está entre 10 ms a 15 ms, Existe algo que possa melhorar direto no banco? Esse processo envolve uma transferência razoável de dados? Caso afirmativo, sugiro que utilize conexão SSL (que compacta o tráfego por padrão) para tentar melhorar esse tempo. Antes que pergunte, não há a possibilidade de compactação sem utilização de conexões SSL. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
(...) Antes que pergunte, não há a possibilidade de compactação sem utilização de conexões SSL. Na verdade tem outras ferramentas que fazem isso, uma que conheço é o Zebedee, mas não sei dizer se é melhor ou não que SSL, acredito que não seja, mas talvez seja uma boa testar uma sobre a outra (quem sabe não melhora, isso se o tráfego for realmente grande, se não a sobrecarga no pré-processamento pode causar problemas). Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
On 06-07-2012 13:01, Matheus de Oliveira wrote: (...) Antes que pergunte, não há a possibilidade de compactação sem utilização de conexões SSL. Na verdade tem outras ferramentas que fazem isso, uma que conheço é o Zebedee, mas não sei dizer se é melhor ou não que SSL, acredito que não seja, mas talvez seja uma boa testar uma sobre a outra (quem sabe não melhora, isso se o tráfego for realmente grande, se não a sobrecarga no pré-processamento pode causar problemas). Zebedee é uma ferramenta sem uma nova versão a muitos anos; talvez ela esteja obsoleta? É claro que há outras maneiras [1] mas conexões SSL visam diminuir o esforço em configuração já que não é necessário outros softwares. [1] http://www.postgresql.org/docs/9.1/static/ssh-tunnels.html -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento de tabela
Em 06-07-2012 09:19, Aldrey Galindo escreveu: Flavio, O problema que me referi foi ao fato de que por algum motivo desconhecido para mim ele ficou com essa sessão travada. Não sei se foi devido ao restart do banco (não apresentou erros). Uma sessão nunca fica travada após o restart do PostgreSQL. Ele sempre sobre limpo, a não ser que alguém se reconecte muito rapidamente e você não perceba a tempo. Lembre-se que sua própria conexão para olhar as coisas *é* uma conexão. Minha pergunta é: o que essa sessão travada estava te causando? Era uma sessão mesmo? Como você visualizou essa sessão, que comandos você deu? A resposta correta a estas perguntas nos ajudará a ajudá-lo melhor. Antes de fazer um backup de tudo e criar um novo banco, eu não sabia o que tinha ocorrido, pois não teve nenhuma mensagem de erro ou aviso. Provavelmente porque não houve nenhum. Pensei que era apenas algo em 1 tabela, mais acabou sendo no banco. Tentei apagar a tabela e recriar ela, apenas ela não fazia nada, ficava parado. Se quando tentei apagar ela, o banco tivesse informado dessa dessão do 'prepared transaction', aí sim o tempo de solução teria sido menor. Ahh, você acha que havia um lock gerado por uma prepared transaction??? Você vê isso na visão de sistema pg_prepared_xacts? É só você dar um ROLLBACK PREPARED na transação!!! Certamente foi uma aplicação que iniciou um 2PC (Two Phase Commit) e não terminou. Prepared Transactions resistem a reinícios do PostgreSQL. Note que estou chutando. Passe-nos seu caminho exato, mas parece que foi isso. Versão: 8.4.5 (ainda não atualizado para a 9.1) SO: RedHat 5 - 64 bits Desculpe pela sujeira na thread, não foi minha intenção. Você não precisa obrigatoriamente ir pra 9.1, mas você é fortemente recomendado a ir para 8.4.12. Tem muito bug corrigido. Não tem a ver com seu problema, de qualquer forma. []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
Re: [pgbr-geral] Comunicação com Banco de dados lenta
Em 06-07-2012 09:32, Lucas de Lima escreveu: Bom dia, Tenho uma aplicação java, mais precisamente um ERP, rodando PostgreSQL 9.1 em um Linux 64 bits. Agora nos surgiu a necessidade de ligar com um outro ponto, e esse só pode ser via link de rádio. O problema é que um processo local demora em torno de 10 segundos, já nesse link está demorando em torno de 30 a 40seg, o ping entre essas redes está entre 10 ms a 15 ms, Provavelmente não é latência, mas a quantidade de dados que têm de trafegar do ponto A para o B. Existe algo que possa melhorar direto no banco? Você terá de diminuir a quantidade de dados que trafegam em cada transação para que elas sejam mais rápidas. Você tem um gargalo em rede. []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
Re: [pgbr-geral] Comunicação com Banco de dados lenta
Zebedee é uma ferramenta sem uma nova versão a muitos anos; talvez ela esteja obsoleta? É claro que há outras maneiras [1] mas conexões SSL visam diminuir o esforço em configuração já que não é necessário outros softwares. Ah, sim, só quis dizer que não é a única solução, podia ser criado até um túnel SSH, que pode ser configurado com compressão de dados também (opção -C). Acho que nesses casos esforço em configuração não seria o ponto importante, geralmente me preocupo mais com o resultado. De qualquer forma acredito (não fiz testes de fato) que o SSL ainda seria melhor que SSH (ou seja, mais rápido). Alguém já testou soluções do tipo? Atenciosamente, -- Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
Em 6 de julho de 2012 13:17, Matheus de Oliveira matioli.math...@gmail.com escreveu: Zebedee é uma ferramenta sem uma nova versão a muitos anos; talvez ela esteja obsoleta? É claro que há outras maneiras [1] mas conexões SSL visam diminuir o esforço em configuração já que não é necessário outros softwares. Ah, sim, só quis dizer que não é a única solução, podia ser criado até um túnel SSH, que pode ser configurado com compressão de dados também (opção -C). Acho que nesses casos esforço em configuração não seria o ponto importante, geralmente me preocupo mais com o resultado. De qualquer forma acredito (não fiz testes de fato) que o SSL ainda seria melhor que SSH (ou seja, mais rápido). Alguém já testou soluções do tipo? Sistemas tipo client/server com conexão de pouco largura de banda são quase impossíveis de manter sem nenhum ajuste no software (seja usando compactação ou diminuindo as requisições da interface). Gostaria de dar mais uma opção: nestes casos é possível reescrever algumas regras de negócio para rodar no banco de dados (functions) evitando assim a transferência de informações entre o servidor e o client. Apesar de serem soluções bem pontuais, podem não resolver 100% o problema do gargalo, mas ajudam. Esta alternativa não ajuda muito caso você possuir as regras de negócio em um servidor de aplicações (JBoss, Glassfish, etc). -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: PgAdmin no Win7
Na mosca Juliano. O problema é este arquivo. Eu renomeei o arquivo e fiz uma consulta. Mas quando fui entrar novamente deu erro. So está funcionando quando exclui/renomeio o arquivo pgadmin_histoqueries.xml Vou tentar uma versão mais antiga do pgAdmin. -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Juliano Benvenuto Piovezan Enviada em: sexta-feira, 6 de julho de 2012 10:26 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] PgAdmin no Win7 2012/7/5 Saulo Morais Lara sa...@abilityonline.com.br: Estou tendo problemas com o PgAdmin, tanto na versão 1.12.3 quanto na 1.14.3. Quando acesso o banco e clico em SQl Queries o PgAdmin para de funcionar. Está parecendo com o bug do arquivo de histórico de consultas. Ele foi corrigido na versão 1.12.3, você chegou a utilizar uma versão anterior? Tente renomear/excluir o arquivo pgadmin_histoqueries.xml presente no diretório %APPDATA%\postgresql\ ___ 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] REF. Lustagem Semanal.
Exatametne isso que eu precisava Fabrízio. Valeu a dicas e obrigado a todos os que responderam. Att, Paulo. - Original Message - From: Fabrízio de Royes Mello To: Comunidade PostgreSQL Brasileira Sent: Friday, July 06, 2012 11:52 AM Subject: Re: [pgbr-geral] REF. Lustagem Semanal. Em 6 de julho de 2012 11:14, pa...@visualpsistemas.com.br escreveu: Ola Pessoal, Tenho a seguinte sentença: select data,nome,valor from entradas where data between '20120601' and '20120630' order by data Preciso listar os dados a partir da data inicial e final, separada por semana. Ex: O mes de Junho tem 5 semanas: 1a) do dia 01 a 02 2a) do dia 03 a 09 3a) do dia 10 a 16 4a) do dia 17 a 23 5a) do dia 24 a 30 Preciso que o resultado seja o seguinte: Semana 01 2012-06-01;ANDRÉ ;200.00 2012-06-01;LUCIO ;175.00 2012-06-03;CELINA ;609.00 Semana 02 2012-06-04;CÉSAR ;570.00 2012-06-04;VOLNEI ;350.00 2012-06-05;AGNALDO ;190.00 2012-06-10;CARLOS ;300.00 2012-06-11;ELIEZER ;500.00 Semana 03 2012-06-21;ERIVAM ;85.00 2012-06-22;ADEMAR ;198.00 Alguem tem alguma dica ??? Quem sabe isso ajude: SELECT EXTRACT(WEEK FROM data) AS semana, data, valor FROM entradas WHERE data BETWEEN '2012-06-01' AND '2012-06-30' ORDER BY semana, data; Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello -- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Nenhum vírus encontrado nessa mensagem. Verificado por AVG - www.avgbrasil.com.br Versão: 2012.0.2195 / Banco de dados de vírus: 2437/5112 - Data de Lançamento: 07/05/12 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
2012/7/6 Tiago Adami adam...@gmail.com: Sistemas tipo client/server com conexão de pouco largura de banda são quase impossíveis de manter sem nenhum ajuste no software (seja usando compactação ou diminuindo as requisições da interface). A rigor, o ideal é que as regras de negócio fiquem todas na base de dados, e preferivelmente declarativamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
Não sei se é possível.Mas manter o ERP e o POSTGRES no mesmo local apenas disponibilizando acesso remoto ao ERP solucionaria o problema. Em 06-07-2012 09:32, Lucas de Lima escreveu: Bom dia, Tenho uma aplicação java, mais precisamente um ERP, rodando PostgreSQL 9.1 em um Linux 64 bits. Agora nos surgiu a necessidade de ligar com um outro ponto, e esse só pode ser via link de rádio. O problema é que um processo local demora em torno de 10 segundos, já nesse link está demorando em torno de 30 a 40seg, o ping entre essas redes está entre 10 ms a 15 ms, Provavelmente não é latência, mas a quantidade de dados que têm de trafegar do ponto A para o B. Existe algo que possa melhorar direto no banco? Você terá de diminuir a quantidade de dados que trafegam em cada transação para que elas sejam mais rápidas. Você tem um gargalo em rede. []s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
Esse processo envolve uma transferência razoável de dados? Caso afirmativo, sugiro que utilize conexão SSL (que compacta o tráfego por padrão) para tentar melhorar esse tempo. Antes que pergunte, não há a possibilidade de compactação sem utilização de conexões SSL. Euler, realmente este processo envolve um transferência razoável de dados, vou buscar mais sobre essas conexões que permitem uma compactação. Isso deveria ser feito na aplicação, certo ? Provavelmente não é latência, mas a quantidade de dados que têm de trafegar do ponto A para o B. Flávio, foi que imaginei também. Ah, sim, só quis dizer que não é a única solução, podia ser criado até um túnel SSH, que pode ser configurado com compressão de dados também (opção -C). Acho que nesses casos esforço em configuração não seria o ponto importante, geralmente me preocupo mais com o resultado. De qualquer forma acredito (não fiz testes de fato) que o SSL ainda seria melhor que SSH (ou seja, mais rápido). Alguém já testou soluções do tipo? Vou realizar alguns testes via tunel SSH também. Obrigado Ats Lucas de Lima -- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Gravando o conteudo de um XML no banco
Senhores, boa tarde , estou tentando gravar o conteudo de um arquivo XML (nf-e) no banco de dados , primeiramente criei um campo do tipo TEXT , nao deu certo porque o conteudo é muito grande , entao modifiquei o campo para XML , e gravei dessa forma : ‘update tabela set espelho_xml=xmlparse(DOCUMENT ‘conteudo do arquivo xml’) where id=99’ , nao gravou nada lendo a documentação do pg descobri que para usar XML é necessario algumas configurações , como o meu banco esta na LOCAWEB , nao sei se esta configurado corretamente , pesquisando descobri que posso usar o campo de tipo BYTEA ou OID . Alguem poderia me dar um dica de qual maneira seria melhor fazer isso ? Desde ja eu agredeço Att Jarbas ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: PgAdmin no Win7 - RESOLVIDO
Pessoal, eu alterei a pasta onde é gravado o histórico de queries e funcionou. Fui em Files Options Query Tool Files History File Path e alterei o caminho. O mais engraçado é que alterei de C:\Users\Usuário\AppData\Roaming\postgresql para C:\Users\Saulo\AppData\Roaming\postgresql So mudou o nome de usuário. Mas eu li que o Windows da uns pau quando o nome do usuário tem acento. Vai saber né. -Mensagem original- De: Saulo Morais Lara [mailto:sa...@abilityonline.com.br] Enviada em: sexta-feira, 6 de julho de 2012 14:02 Para: 'Comunidade PostgreSQL Brasileira' Assunto: RES: [pgbr-geral] PgAdmin no Win7 Na mosca Juliano. O problema é este arquivo. Eu renomeei o arquivo e fiz uma consulta. Mas quando fui entrar novamente deu erro. So está funcionando quando exclui/renomeio o arquivo pgadmin_histoqueries.xml Vou tentar uma versão mais antiga do pgAdmin. -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Juliano Benvenuto Piovezan Enviada em: sexta-feira, 6 de julho de 2012 10:26 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] PgAdmin no Win7 2012/7/5 Saulo Morais Lara sa...@abilityonline.com.br: Estou tendo problemas com o PgAdmin, tanto na versão 1.12.3 quanto na 1.14.3. Quando acesso o banco e clico em SQl Queries o PgAdmin para de funcionar. Está parecendo com o bug do arquivo de histórico de consultas. Ele foi corrigido na versão 1.12.3, você chegou a utilizar uma versão anterior? Tente renomear/excluir o arquivo pgadmin_histoqueries.xml presente no diretório %APPDATA%\postgresql\ ___ 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] Gravando o conteudo de um XML no banco
2012/7/6 jar...@softtecsoftware.com.br: Senhores, boa tarde , estou tentando gravar o conteudo de um arquivo XML (nf-e) no banco de dados , primeiramente criei um campo do tipo TEXT , nao deu certo porque o conteudo é muito grande , entao modifiquei o campo para XML , e gravei dessa forma : ‘update tabela set espelho_xml=xmlparse(DOCUMENT ‘conteudo do arquivo xml’) where id=99’ , nao gravou nada lendo a documentação do pg descobri que para usar XML é necessario algumas configurações , como o meu banco esta na LOCAWEB , nao sei se esta configurado corretamente , pesquisando descobri que posso usar o campo de tipo BYTEA ou OID . Alguem poderia me dar um dica de qual maneira seria melhor fazer isso ? Desde ja eu agredeço Att Jarbas eu tentaria como bytea -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Gravando o conteudo de um XML no banco
Em 06-07-2012 15:08, jar...@softtecsoftware.com.br escreveu: Senhores, boa tarde , estou tentando gravar o conteudo de um arquivo XML (nf-e) no banco de dados , primeiramente criei um campo do tipo TEXT , nao deu certo porque o conteudo é muito grande , entao modifiquei o A limitação de tamanho para campo text é de 1GB. Seu XML é tão grande assim? campo para XML , e gravei dessa forma : ‘update tabela set espelho_xml=xmlparse(DOCUMENT ‘conteudo do arquivo xml’) where id=99’ , nao gravou nada A documentação do xmlparse está aqui: http://www.postgresql.org/docs/9.1/static/datatype-xml.html Deveria ter funcionado. lendo a documentação do pg descobri que para usar XML é necessario algumas configurações , como o meu banco esta na LOCAWEB , nao sei se esta configurado corretamente , pesquisando descobri que posso usar o campo de tipo BYTEA ou OID . O campo deveria ser tipo xml mesmo. Você tem que setar como vai passar o XML (document ou content). Alguem poderia me dar um dica de qual maneira seria melhor fazer isso ? Conecte-se ao banco e execute: SHOW xmloption; Veja o que sai. Como a configuração pode ser feita por sessão ou usuário, você só precisa fazer: SET xmloption = 'o que você precisar'; Antes de executar o xmlparse e xmlserialize. Não precisa alterar configuração no servidor. Aproveite e faça um: SHOW version; Pra saber qual a versão do PostgreSQL que o seu fornecedor está te disponibilizando. []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] Fw: Gravando o conteudo de um XML no banco
Itamar obrigado pela dica , vou pesquisar como gravar campos BYTEA . Att Jarbas -Mensagem Original- From: Itamar Reis Peixoto Sent: Friday, July 06, 2012 3:14 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Gravando o conteudo de um XML no banco 2012/7/6 jar...@softtecsoftware.com.br: Senhores, boa tarde , estou tentando gravar o conteudo de um arquivo XML (nf-e) no banco de dados , primeiramente criei um campo do tipo TEXT , nao deu certo porque o conteudo é muito grande , entao modifiquei o campo para XML , e gravei dessa forma : ‘update tabela set espelho_xml=xmlparse(DOCUMENT ‘conteudo do arquivo xml’) where id=99’ , nao gravou nada lendo a documentação do pg descobri que para usar XML é necessario algumas configurações , como o meu banco esta na LOCAWEB , nao sei se esta configurado corretamente , pesquisando descobri que posso usar o campo de tipo BYTEA ou OID . Alguem poderia me dar um dica de qual maneira seria melhor fazer isso ? Desde ja eu agredeço Att Jarbas eu tentaria como bytea -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) ___ 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] Comunicação com Banco de dados lenta
Não sei se é possível.Mas manter o ERP e o POSTGRES no mesmo local apenas disponibilizando acesso remoto ao ERP solucionaria o problema. Gilmar, Sim eu tenho uma solução assim, são 15 computadores nesse ponto B, onde na sua maioria eu utilizo acesso remoto (NX), mas para esse caso é específico pois é um terminal para emissão de cupom fiscal, e eu só consigo comunicar com a ecf assim,por enquanto. Alguém já passou por algo nesse sentido? -- Ats. Lucas de Lima ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Gravando o conteudo de um XML no banco
Flavio , obrigado pelas informações : Me expressei mal , a limitação não está no campo TEXT e sim no tamanho da query para grava-lo , visto que fica dessa forma : update tabela espelho_xml='?xml version=1.0 encoding=UTF-8 ? - nfeProc xmlns=http://www.portalfiscal.inf.br/nfe; versao=2.00- NFe xmlns=http://www.portalfiscal.inf.br/nfe;- infNFe d=NFe35120605636104000100550011100011 versao=2.00- ide cUF35/cUF cNF0001/cNF natOpVENDAS/natOp indPag1/indPag . . . ' Fiz o comando : SHOW xmloption; e o resultado foi : content Fiz o comando : SHOW version; e o resultado foi erro : ERROR: unrecognized configuration parameter version Desde ja agradeço. Att Jarbas -Mensagem Original- From: Flavio Henrique Araque Gurgel Sent: Friday, July 06, 2012 3:33 PM To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Gravando o conteudo de um XML no banco Em 06-07-2012 15:08, jar...@softtecsoftware.com.br escreveu: Senhores, boa tarde , estou tentando gravar o conteudo de um arquivo XML (nf-e) no banco de dados , primeiramente criei um campo do tipo TEXT , nao deu certo porque o conteudo é muito grande , entao modifiquei o A limitação de tamanho para campo text é de 1GB. Seu XML é tão grande assim? campo para XML , e gravei dessa forma : ‘update tabela set espelho_xml=xmlparse(DOCUMENT ‘conteudo do arquivo xml’) where id=99’ , nao gravou nada A documentação do xmlparse está aqui: http://www.postgresql.org/docs/9.1/static/datatype-xml.html Deveria ter funcionado. lendo a documentação do pg descobri que para usar XML é necessario algumas configurações , como o meu banco esta na LOCAWEB , nao sei se esta configurado corretamente , pesquisando descobri que posso usar o campo de tipo BYTEA ou OID . O campo deveria ser tipo xml mesmo. Você tem que setar como vai passar o XML (document ou content). Alguem poderia me dar um dica de qual maneira seria melhor fazer isso ? Conecte-se ao banco e execute: SHOW xmloption; Veja o que sai. Como a configuração pode ser feita por sessão ou usuário, você só precisa fazer: SET xmloption = 'o que você precisar'; Antes de executar o xmlparse e xmlserialize. Não precisa alterar configuração no servidor. Aproveite e faça um: SHOW version; Pra saber qual a versão do PostgreSQL que o seu fornecedor está te disponibilizando. []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] Gravando o conteudo de um XML no banco
Em 06-07-2012 16:21, jar...@softtecsoftware.com.br escreveu: Flavio , obrigado pelas informações : Me expressei mal , a limitação não está no campo TEXT e sim no tamanho da query para grava-lo , visto que fica dessa forma : update tabela espelho_xml='?xml version=1.0 encoding=UTF-8 ? - nfeProc xmlns=http://www.portalfiscal.inf.br/nfe; versao=2.00-NFe xmlns=http://www.portalfiscal.inf.br/nfe;-infNFe d=NFe35120605636104000100550011100011 versao=2.00-ide cUF35/cUFcNF0001/cNFnatOpVENDAS/natOp indPag1/indPag . . . ' Fiz o comando : SHOW xmloption; e o resultado foi : content Me parece ser isso que você precisa, certo? Fiz o comando : SHOW version; e o resultado foi erro : ERROR: unrecognized configuration parameter version Desculpe, minha falha. O certo é: SELECT version(); []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
Re: [pgbr-geral] Comunicação com Banco de dados lenta
Em 6 de julho de 2012 16:16, Lucas de Lima lucas...@gmail.com escreveu: Não sei se é possível.Mas manter o ERP e o POSTGRES no mesmo local apenas disponibilizando acesso remoto ao ERP solucionaria o problema. Gilmar, Sim eu tenho uma solução assim, são 15 computadores nesse ponto B, onde na sua maioria eu utilizo acesso remoto (NX), mas para esse caso é específico pois é um terminal para emissão de cupom fiscal, e eu só consigo comunicar com a ecf assim,por enquanto. Alguém já passou por algo nesse sentido? Já. A solução foi adaptar o software para ter seu próprio banco de dados e replicar os dados full-duplex com o servidor. Assim você não tem tanto tráfego de rede - limita-se à subir vendas e baixar preços e dados cadastrais, mas torna seu aplicativo assíncrono (ou semi off-line). A última empresa onde trabalhei tem um software assim, rodando em Windows com PostgreSQL 8.3 (não sei se já atualizaram). Funciona muito bem, diga-se de passagem (exceto quando o equipamento dos caixas são ruins e corrompem o banco de dados). Se você caprichar, pode até elaborar uma maneira de transferir os dados de forma compactada. O software de replicação que citei é próprio, customizado, replica dados de PostgreSQL para Sybase e DB2 e destes para o PostgreSQL também. Claro que replicação heterogênea, incremental e customizada envolvendo dois ou mais SGBDs distintos requisitam um projeto bem elaborado, e com certeza você precisará de subsídios para controlar quais registros irão ser replicados (com o auxílio de alguns triggers isso pode ser feito sem maiores problemas). Assim não é necessário uma carga completa via ETL toda vez que subir vendas ou baixar preços. Existem algumas ferramentas pagas que fazem isso de forma transparente, mas são muito caras (como o Sybase Replicator). Desconheço alguma livre. E também, se eu não me engano, seu software já deveria estar funcionando com um banco de dados independente por causa das regras do PAF-ECF. Resumindo: não tem como fugir desta alternativa, e você já acaba matando dois coelhos com uma caixa d'água só :) -- TIAGO J. ADAMI http://www.adamiworks.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] Comunicação com Banco de dados lenta
On 06-07-2012 14:57, Lucas de Lima wrote: Euler, realmente este processo envolve um transferência razoável de dados, vou buscar mais sobre essas conexões que permitem uma compactação. Isso deveria ser feito na aplicação, certo ? Sim. Compactar antes de transmitir e descompactar após receber. O PostgreSQL ainda *não* oferece uma solução para compactação dos dados trafegados no seu próprio protocolo. Recentemente eu abri uma discussão para implementar isso (sem depender de conexões SSL ou túneis SSH) e espero terminar o trabalho a tempo para 9.3. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comunicação com Banco de dados lenta
2012/7/6 Euler Taveira eu...@timbira.com: Recentemente eu abri uma discussão para implementar isso (sem depender de conexões SSL ou túneis SSH) e espero terminar o trabalho a tempo para 9.3. Parabéns, Euler! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Npgsql 2.0.12 (beta4) released
Hi, all!! The Npgsql Development Team is proud to announce the Npgsql2 2.0.12 beta4 release! Npgsql is a .Net Data provider written 100% in C# which allows .net programs to talk to postgresql backends. Npgsql is licensed under BSD. More info can be obtained from http://www.npgsql.org This release is a minor bug fix for the stable 2.0 series and may be the last release towards 2.0.12 stable. Bug fixes: [#1011200] Uses API not supported in MonoTouch. [#1011161] Bug in NpgsqlCommand while getting readers from refcursors. Thanks Rabin Karki for heads up and patch. [#1011174] Requesting the REPEATABLE READ isolation level gives [#1011208] Fix Include combined with Skip and/or Take using linq to entities for bug #1011208 You can download it from here: http://downloads.npgsql.org Thank you to Josh Cooley for all his help with entity framework support and many other things! Thank you to all who sent feedbacks, suggestions and patches. You helped to make this release. Please, feel free to give it a try and let us know if you find any problems. -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://www.npgsql.org http://gplus.to/franciscojunior http://fxjr.blogspot.com http://twitter.com/franciscojunior ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
