Re: [pgbr-geral] [pgbr-dev] PGDay PR: Cascavel abraça o Postgres!
Olá pessoal, Legal ver o caso. Vocês lembraram de divulgar o Latinoware? Talvez seria o caso de entrar em contato com os organizadores e pedir um apoio na divulgação do que vamos fazer em Foz. Sobre o evento em outros locais, tem 100% de meu apoio. > > -- Eduardo Santos Analista de Sistemas http://www.eduardosan.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Consultoria em monitoramento PostgreSQL com o Cedrus
Pessoal, Estamos com uma demanda sobre o Cedrus e tenho dado uma "garibada" no código para funcionar nas últimas versões do Rails. Também temos que dar uma melhorada na documentação, enfim, tornar o software mais apresentável. Alguém que conheça a plataforma está a fim de prestar um serviço de consultoria para torná-lo mais "apresentável" a funcional? Interessados enviem uma mensagem em PVT para eduardo.san...@lightbase.com.br -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ERP livre PostgreSQL Brasil
Dutra, Eu utilizo o project-open há algum tempo e acho muito bom, principalmente para gerências financeiras e de TIC. Dê uma olhada: http://www.project-open.com/ -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF-TOPIC - Vaga para DBA PostgreSQL
Gente, É possível que a oferta de vagas hoje seja baixa, mas tenho certeza que se criarmos um canal para isso dentro da comunidade e divulgarmos sua existência as vagas vão aparecer. Imaginem: se alguém precisar de um DBA PostgreSQL vai saber exatamente para onde mandar. Essa lista poderia ser moderada com envio aberto, assim se alguém que não fizer parte da lista quiser enviar o moderador pode decidir se publica ou não. Mais uma reflexão para fomentar a discussão: que mal tem criar a lista de vagas? Não haveria uma necessidade grande de armazenamento ou algo assim, apenas uma lista de e-mail para divulgar as vagas. Como inspiração, fica a lista PHP Empregos: http://br.dir.groups.yahoo.com/group/php-empregos/?v=1&t=directory&ch=web&pub=groups&sec=dir&slk=4 Conheço muita gente que conseguiu vaga pela lista. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF-TOPIC - Vaga para DBA PostgreSQL
Que tal criar a lista PostgreSQL-vagas logo e esperar que as pessoas comecem a enviar? Alguém? Em 9 de janeiro de 2012 11:01, JotaComm escreveu: > Opa, seu Flávio > > Em 7 de janeiro de 2012 23:50, Flavio Henrique Araque Gurgel < > fha...@gmail.com> escreveu: > > > Olá colegas! >> > >> > Aproveitando o grande movimento nesta lista, gostaria de anunciar mais >> > uma vaga para Analista de Suporte PostgreSQL. Ainda é extra-oficial, >> > portanto não foi nem promulgado no site da empresa. Segue abaixo a >> > oportunidade: >> >> (...) >> >> Não achei nada off-topic :) >> Quem me dera houvessem tantas mensagens de vagas que tivéssemos de >> criar uma lista só pra isso! >> > > Concordo plenamente com você. > >> >> []s >> Flavio Gurgel >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > Abraços > -- > JotaComm > http://jotacomm.wordpress.com > > _______ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Brutal queda de performance atualizando de 8.2 para 8.4
Olá Osvaldo, Obrigado pela resposta. Seguem comentários: > Pelos números apresentados tudo indica que suas estatísticas estavam > atualizadas o que levou o planejador a optar por caminhos > ineficientes. > Veja por exemplo: > > Nested Loop (cost=0.00..982907.73 rows=397639583 width=4) (actual > time=0.102..1117.157 rows=1396734 loops=67) > > ele estimou que existiriam 397.639.583 linhas quando, na realidade, > existiam 1.396.734 linhas. > > Rode novamente sua consulta com as estatísticas atualizadas e avalie o > resultado. > > A versão que você está utilizando é a 8.4.9? > Eu executei o vacuum full com analyze, rodei novamente a consulta e não obtive resultados muito diferentes. A versão é a 8.4.9 sim. Seria necessário executar o vacuum mesmo com o autovacuum ligado? Também não entendi como ele conseguiu ter resultados tão diferentes entre duas versão do PostgreSQL, mas aconteceu. Euler, Seguem respostas: 8.4.oque? 8.4.9 > Você executou a EXPLAIN ANALYZE várias vezes para se certificar de > que a diferença de tempo não é por causa de uma "partida a frio" da versão > 8.4? Sim, essa foi a primeira coisa que pensei. Executei várias vezes e os resultados não mudam muito. > Qual é a consulta? Desculpe, esqueci de anexar a consulta. É uma consulta realmente feia, mas que não chegava a ser um desastre no banco: select forums_forums.package_id, acs_object__name(apm_package__parent_id(forums_forums.package_id)) as parent_name, (select site_node__url(site_nodes.node_id) from site_nodes where site_nodes.object_id = forums_forums.package_id) as url, forums_forums.forum_id, forums_forums.name, case when last_post > (cast(current_timestamp as date)- 1) then 't' else 'f' end as new_p from forums_forums_enabled forums_forums, acs_objects where acs_objects.object_id = forums_forums.forum_id and forums_forums.package_id in (0,840191,1486834,626929,520062,1101742,1160464,1161067,2750196,3500360,133998,3673774,3676596,3686932,4860207,5986896,10050612,10157702,4645,93855,3186091,601355,22297512,6552691,21650654,8265465,23731964,33752302,15316177) and exists ( select 1 from acs_object_party_privilege_map ppm where ppm.object_id = forums_forums.package_id and ppm.party_id = '3443' and ppm.privilege = 'read_private_data' ) order by parent_name, forums_forums.name Uma das coisas que me chamaram atenção foi a estimativa do índice > acs_obj_ctx_idx_ancestor_idx. Qual a definição da tabela > acs_object_context_index? A definição é a seguinte: Tabela "public.acs_object_context_index" Coluna | Tipo | Modificadores ---+-+--- object_id | integer | não nulo ancestor_id | integer | não nulo n_generations | integer | não nulo Índices: "acs_object_context_index_pk" PRIMARY KEY, btree (object_id, ancestor_id) "acs_obj_ctx_idx_ancestor_idx" btree (ancestor_id) "acs_obj_ctx_idx_object_id_idx" btree (object_id) Restrições de verificação: "acs_obj_context_idx_n_gen_ck" CHECK (n_generations >= 0) Restrições de chave estrangeira: "acs_obj_context_idx_anc_id_fk" FOREIGN KEY (ancestor_id) REFERENCES acs_objects(object_id) "acs_obj_context_idx_obj_id_fk" FOREIGN KEY (object_id) REFERENCES acs_objects(object_id) Ela funciona como uma tabela intermediária para facilitar a contagem da quantidade de filhos que determinado objeto tem. É uma tentativa de evitar a contagem num subselect, o que tornaria a consulta ainda mais lenta. Sabe me dizer se houve alguma mudança significativa no otimizados entre as versões 8.2 e 8.4? -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Brutal queda de performance atualizando de 8.2 para 8.4
Olá Dutra, Obrigado pela resposta. Seguem comentários. Em 12 de novembro de 2011 12:14, Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org> escreveu: > Le 2011-N-12 11h38, Eduardo Santos a écrit : > > >> Estava com alguns problemas de lock >> > > Que problemas? Normalmente, a questão não é versão mas programação do > aplicativo… É um problema que até a versão 8.1 gerava deadlock no PostgreSQL: uma função PL/pgSQL, chamada em uma transação, que chama uma outra função PL/pgSQL em outra transação. Um ciclo de 5 ou 6 funções chamadas dentro de transações. O problema maior não é esse, contudo. A questão é que a sequência de funções pode ser chamada várias vezes dentro da aplicação. Assim, enquanto a tabela está sendo chamada por uma consulta, ela está travada pela transação. No meio disso tudo, existe uma outra chamada para a transação, que só vai ser executada após a primeira trava ser liberada. Difícil de explicar dada a complexidade da chamada, mas o fato é que temos muitos locks em sequência da mesa linha na mesma tabela. Como essa é a parte que mais evoluiu, achei quem um upgrade ia me ajudar. Sim, o aplicativo poderia realizar uma chamada mais atômica de uma única função PL/pgSQL e resolver o problema, mas estou adiando isso até não ter mais jeito. O trabalho de reescrita seria simplesmente construir o sistema novamente, e não posso me dar a esse luxo enquanto o sistema está lento para os usuários. > > decidi atualizar minha versão do PostgreSQL da 8.2 para a 8.4 >> > > Por que para uma versão tão antiga? Já estamos na 9.1, que avançou bem > mais em relação à 8.4 que a 8.4 em relação à 8.2. > > Problemas de retro-compatibilidade que ainda não tive tempo de resolver. Como removeram as cláusulas add_missing_from e regex_flavour na versão 9.0, ainda não posso atualizar. Também é algo que pode ser resolvido, com tempo que ainda não tenho. A ideia era resolver após o sistema ficar mais rápido. > > Contudo, para minha surpresa, a performance caiu drasticamente. O >> curioso é que as máquinas físicas são idênticas fisicamente e mantive >> exatamente os mesmos parâmetros de configuração para o PostgreSQL. >> > > Essas não são as únicas variáveis. Só de cabeça, sem gastar muito > fosfato, vêm sistema operacional, sistemas de arquivos e configuração dos > mesmos; e coleta de estatísticas. > Essa é a questão: as máquinas são fisicamente iguais, com os mesmos softwares instalados e mesmas configurações de SO. Fiz questão de checar duas vezes para garantir um ambiente replicado. Até o disco é o mesmo. >Como os planos de execução foram bem diferentes, eu apostaria em > diferenças ou na estrutura dos dados; ou no texto da consulta; ou na massa > de dados; ou na configuração do PostgreSQL ou na coleta de estatísticas, > todos pontos a verificar urgentemente, e informar aqui. > > Essa foi a ideia que eu tive. Me parece que houve muitas mudanças no otimizados. Consegui achar duas referências: http://postgresql.1045698.n5.nabble.com/query-taking-much-longer-since-Postgres-8-4-upgrade-td3787736.html http://postgresql.1045698.n5.nabble.com/A-query-become-very-slow-after-upgrade-from-8-1-10-to-8-4-5-td3246107.html Nenhuma das duas foi conclusiva, contudo. O fato é que o otimizador escolhe um nested loop com um semi join na versão do 8.4, enquanto no 8.1 a opção escolhida é primeiro ordenar utilizando um bitmap heap scan. Infelizmente meus conhecimentos de otimização do otimizador (desculpe o pleonasmo) não me permitiram resolver o problema ainda. Alguma ajuda com dicas de configuração seria bem-vinda. Mais uma vez, obrigado pela resposta em pleno Sabadão! :) -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Brutal queda de performance atualizando de 8.2 para 8.4
-> Index Scan using acs_objects_pk on acs_objects (cost=0.00..8.77 rows=1 width=4) (actual time=0.014..0.016 rows=1 loops=67) Index Cond: (acs_objects.object_id = public.forums_forums.forum_id) -> Nested Loop (cost=0.00..982907.73 rows=397639583 width=4) (actual time=0.102..1117.157 rows=1396734 loops=67) -> Nested Loop (cost=0.00..12218.50 rows=45973 width=4) (actual time=0.073..0.487 rows=92 loops=67) Join Filter: ((p.privilege)::text = (pdm.privilege)::text) -> Seq Scan on acs_privilege_descendant_map pdm (cost=0.00..9.23 rows=3 width=13) (actual time=0.025..0.025 rows=1 loops=67) Filter: ((descendant)::text = 'read_private_data'::text) -> Nested Loop (cost=0.00..549.81 rows=281596 width=14) (actual time=0.037..0.364 rows=231 loops=67) -> Index Scan using party_member_member_idx on party_approved_member_map pamm (cost=0.00..25.68 rows=18 width=4) (actual time=0.018..0.018 rows=1 loops=67) Index Cond: (member_id = 3443) -> Index Scan using acs_permissions_grantee_idx on acs_permissions p (cost=0.00..28.92 rows=16 width=18) (actual time=0.015..0.255 rows=231 loops=67) Index Cond: (p.grantee_id = pamm.party_id) -> Index Scan using acs_obj_ctx_idx_ancestor_idx on acs_object_context_index c (cost=0.00..13.14 rows=638 width=8) (actual time=0.008..6.993 rows=15182 loops=6164) Index Cond: (c.ancestor_id = p.object_id) SubPlan 1 -> Index Scan using site_nodes_object_id_idx on site_nodes (cost=0.00..8.52 rows=1 width=4) (actual time=0.266..0.268 rows=1 loops=67) Index Cond: (object_id = $0) Total runtime: *95704.632* ms (26 registros) As diferenças entre as decisões tomadas pelo otimizador são tão absurdas que não sei nem por onde começar. Será que alguém pode me dar uma luz? -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [pgbr-dev] Acontecimentos ONG BrOffice e posicionamento
Gente, Gostaria de fazer uma reflexão um pouco mais profunda com vocês, uma vez que temos algumas características que nos diferenciam dos outros produtos de Software Livre do Mercado. Se você acha tais reflexões muito chatas ou desnecessárias, sinta-se à vontade para apagar a mensagem. Nossas principais características são: 1 - Tratamos de um software EXTREMAMENTE importante para qualquer organização. Afinal, dado é a vida inteira da empresa, muito mais que dinheiro; 2 - Somos uma comunidade bastante difusa com foco no conhecimento técnico, normalmente de onde vem a meritocracia; 3 - Estamos crescendo muito, e muito rápido. Como alguns que estão na lista, imaginar que saímos do PostgreSQL 7.1 para onde estamos agora é simplesmente incrível, tanto pelos avanços técnicos quanto pelo crescimento da comunidade. O que crescemos nos últimos 4 anos é tão incrível que perdi a capacidade de acompanhar. Infelizmente, devo dizer que sou um pessimista em determinados temas por natureza. Não acredito que tudo o que aconteceu na ONG BrOffice foi por acaso, assim como descobrimos recentemente que tudo o que aconteceu na discussão do OpenXML também não foi por acaso. Acredito que houve alguém ou algo por trás maior que agiu somente para desestabilizar a ONG e atacar justamente a credibilidade do software, fator que sempre foi um empecilho e vinha crescendo muito nos últimos anos. Justamente por acreditar nisso, algumas coisas que acho que deveríamos pensar juntos: - A quem pertence o nome PostgreSQL? - Qual a influência das grandes empresas na gerência do código? - O que impede que o nosso software (PostgreSQL) sofra um golpe semelhante? Um exercício de reflexão: o que aconteceria se tivéssemos que mudar o nome de PostgreSQL para ElefanteSQL, por exemplo? Qual o impacto que isso teria em nossas vidas? Conseguiríamos vendê-lo tão bem quanto hoje? Acredito que a primeira "investida" foi frustrada, quando a Sun tentou "tomar de assalto" o PostgreSQL, mas não sei se estamos 100% seguros. Talvez seja a hora de imaginarmos como poderemos nos defender das próximas iniciativas que certamente acontecerão. -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres + Hearbeat
Olá Fabrício, Sinceramente, não teria a mesma coragem que você para utilizar DRBD + Heartbeat na partição dos dados. O risco de inconsistência é muito grande, principalmente por causa so Split Brain ( http://linux-ha.org/wiki/Split_Brain). Sugiro repensar sua solução para algo próximo do Warm Stand By, seguindo esse tutorial do João Cosme: http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/ <http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/>Atente-se ao comentário do Telles sobre os problemas da utilização do NFS para detectar a queda do banco. Abraços Em 30 de setembro de 2010 12:20, escreveu: > Ola! > Fiz isto que vc informou abaixo, porem ele não alterou a localização do > .pid, ele apenas passou a gravar o postmaster.pid alem do local de origem > dentro de /data passou a tambem ser gravado no local que defeni nesta > configuração. > > > > Em 29 de setembro de 2010 20:08, escreveu: > > > >> > >> Estou utilizando o drbd + hearbeat para ter um postgresql com alta > >> disponibilidade, porem quando provoco uma queda do servidor master o > slave > >> entra normalmente, porem o postgresql não inicializa porque exite o > arquivo > >> postmaster.pid dentro do diretório /data que por sua vez veio replicado > pelo > >> drbd. > >> O problema ocorre devido o arquivo postmaster.pid ser criado no mesmo > >> diretório que esta o data, assim tambem sendo replicado junto com o > banco. > >> Tentei criando um script removendo o postmaster.pid antes do servidor > >> secundario subir o postres, porem acontece algumas veses o heartbeat > enviar > >> alguma informação de start, status, que acaba removendo o postmaster.pid > do > >> servidor secundario, e ai quando e necessario eu parar e iniciar o > serviço > >> não existe o postmaster.pid no servidor slave. > >> Se alguem tiver alguma sugestão agradeço. > >> > >> > > Quem sabe colocar o arquivo do PID em outra partição!!! Altere a GUC > > "external_pid_file" [1] no postgresql.conf. > > > > [1] > > > http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html > > > > -- > > Fabrízio de Royes Mello > >>> Blog sobre TI: http://fabriziomello.blogspot.com > >>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello > > ___ > > 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 > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF-TOPIC] Full Text Search
Olá Jorge, Sugiro que vc dê uma olhada na documentação do tsearch: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch2-guide.html <http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch2-guide.html>É possível utilizar uma tabela de dicionários, que permite cadastrar significados similares de palavras. Dê ainda uma olhada em 'vectors' e 'queries'. Em 30 de setembro de 2010 11:46, Jorge Vilela escreveu: > Olá pessoal, desculpem pelo OFF-TOPIC, mas já tentei resolver só no > postgres e não consegui. > > Estou com um problema e gostaria de saber se alguém pode me ajudar. > > Tenho uma tabela de produtos em PostgreSQL com aproximadamente 5 milhões de > registros. > Os usuários fazem buscas complexas, como: > pneu da rang > peneus da ranger > pireli para ran > ranger pneu > pneu com câmara para usar na ford ranger > > Hoje utilizo o suporte a FTS do PostgreSQL, porém, não busca "meias > palavras". Se eu troco para o simples ilike o tempo de execução sobe demais, > deixando o sistema lento e vulnerável. > > Além do suporte à meias palavras, preciso do suporte a sinônimos e > fonética. Já tentei o FTS do Mysql mas também não resolve. > > Alguém já conseguiu implementar algo semelhante? Já conseguiu utilizar > Lucene, sphinx, TBGSearch etc (com php, com essas características)? > Qual solução vocês adotaram? > > > Obrigado, > Jorge Vilela > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PGCON 2010, será em Brasília?
Olá Gabriel, Essa questão está sendo discutida em outra lista, a pgbr-dev. Sugiro que faça a sua pergunta por lá, pois é pertinente à organização da comunidade. Em 24 de maio de 2010 08:32, GABRIEL DOS SANTOS escreveu: > Bom dia a todos da Comunidade, > > Estava sendo discutido a realização do PGCON 2010 em Brasília, > já foi definido realmente se será em Brasília? E será no Centro de > Convenções Ulysses Guimarães? > Já foi definido a data, pois neste ano estamos com planos de levar a nossa > equipe desenvolvimento > que estamos formando aqui na empresa. > > > Boa semana a todos vocês. > > > Gabriel dos Santos. > > -- > POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE > SEGURANÇA.<http://www.microsoft.com/brasil/windows/internet-explorer/features/navegue.aspx?tabid=1&catid=1&WT.mc_id=1565> > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ajuda pl-tcl
Olá José Antonio, Qual a versão do PostgreSQL que você está usando? Em 15 de março de 2010 16:18, José Antônio (YMAIL) escreveu: > > > > > Preciso de ajuda para ativar o pltcl no postgres Windows, recebo a mensagem > could not load library. > > > > Ta no path ../lib mas não cria a linguavem. > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ 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: Problemas com Procedure no Linux
Olá Marcos, Esse erro normalmente indica que você esqueceu de declarar a variável tmp_table_tbg_01 no corpo da função. Tem como você colocar todo o código da função? Principalmente o cabeçalho (declare)? 2009/12/17 marcos thomaz > Marcelo, antes de mais nada, obrigado pela ajuda. > Quanto a versão, de ambos os S.O's é a 8.2.0. > > A mensagem de erro gerada é essa: > > ERROR: syntax error at "tmp_table_tbg_01" > SQL state: 42601 > Detail: Expected record variable, row variable, or list of scalar variables > following INTO. > Context: compile of PL/pgSQL function "ajustarptanual" near line 15 > > > > A linha na procedure onde dá o erro é a seguinte: > > select coalesce(localidade,26) as localidade, coalesce(categoria,34) as > categoria, refmm, sum(valor) as valor into tmp_table_tbg_01 from > func_valor_arrecadacao( vMes ) group by 1,2,3; > > > > O log: > > 2009-12-17 18:16:47 ERROR: syntax error at "tmp_table_tbg_01" > 2009-12-17 18:16:47 DETAIL: Expected record variable, row variable, or > list of scalar variables following INTO. > 2009-12-17 18:16:47 CONTEXT: compile of PL/pgSQL function "ajustarptanual" > near line 15 > > > []'s > > Marcos Thomaz > > > > > -- > *De:* Marcelo Costa > *Para:* Comunidade PostgreSQL Brasileira < > pgbr-geral@listas.postgresql.org.br> > *Enviadas:* Quinta-feira, 17 de Dezembro de 2009 16:28:50 > *Assunto:* Re: [pgbr-geral] Problemas com Procedure no Linux > > Olá > > 2009/12/17 marcos thomaz > >> Pessoal, tenho um banco de dados que rodava numa máquina com Windows 2003, >> versão 8.2 do banco de dados. A empresa optou por modificar algumas coisas e >> substituímos o sistema operacional. Trocamos de Windows 2003 para Linux - >> Slackware. Mantivemos a versão do banco, porém, depois disso começou a >> surgir alguns erros em procedures que existiam no banco de dados, todos >> vinculados a sintaxe do tipo: >> >> select coluna1, coluna2, coluna3 into NovaTabela from Tabela Where >> condição. >> >> >> Esse tipo de instrução está funcionando se eu executar diretamente, mas >> dentro da procedure está dando erro e o banco não consegue executar essas >> procedures. Alguém teria alguma idéia? >> > > > 1. Se você enviar os logs do PostgreSQL e as mensagens de erro da tua > procedure certamente te ajudaremos > > 2. Se vc descrever direitinho a versão do PostgreSQL no windows e a que > você utiliza no linux também poderemos te ajudar mais. > > Blz ? > > Atte, > > -- > Marcelo Costa > www.marcelocosta.net > - > “You can't always get what want”, > > Doctor House in apology to Mike Jagger > > -- > Veja quais são os assuntos do momento no Yahoo! + Buscados: Top > 10<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/>- > Celebridades<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/>- > Música<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/>- > Esportes<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/> > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Contatos em Brasília
Olá Coronel, Não se se ficou sabendo, mas tivemos um dia inteiro sobre PostgreSQL em Brasília, que foi organizado no Ministério do Planejamento, onde trabalho: http://www.postgresql.org.br/eventos/pgday/df Se quiser mais informações ou precisar de ajuda em alguma coisa, mande um e-mail pra mim em PVT que te respondo. Abraços 2009/5/12 Jefferson A. L. Pita > Senhores (as), > > >Estou em Brasília. Sou do Exército. Estamos precisando desencadear > uma campanha de massificação do conhecimento sobre o PostGreSQL com os > nossos técnicos na área de informática. > >Sofremos da massificação da cultura Oracle. Queremos inverter este > processo nocivo. > >Desejamos promover uma série de cursos sobre o PostGreSQL, aqui em > Brasília. Precisamos de instrutores/professores, que façam parte do > Projeto PG, para acertarmos uma parceria. > > > Cel LEMOS PITA > (61) 3415-5204 > coronellemosp...@gmail.com > asse2a...@dct.eb.mil.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] Governo Federal lança novo portal d e Software Livre
Desculpem, esqueci o OFF-topic. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
