Mas ontem terminamos o evento. Como sempre, muitos problemas, muito mais do que os participantes do evento possam imaginar. Muitos erros, mas também muito aprendizado com os erros das edições anteriores.

Novos patrocinadores, novos palestrantes, novos temas, novos organizadores, novos participantes, novos clientes, novas idéias. Sim. Muita coisa nova. Sobre tudo, novos amigos, novas perspectivas, novos horizontes.

Se o primeiro PGCon Brasil, em 2007, foi um marco em termos de organização da comunidade, hoje, em 2009 temos um novo marco. As pessoas bateram à  nossa porta, entraram no evento, subiram no palco e disseram: “Hey, nós estamos utilizando o PostgreSQL em missão crítica aqui, precisamos da ajuda de vocês”. Sim, o PostgreSQL está crescendo e tomando de assalto grandes CPDs. Não é mais algo que entra pela porta dos fundos. Muita gente já testou, já sabe que funciona e também conhece suas peculiaridades. Já temos casos de implantações grandes rodando há alguns anos. Não é mais uma aventura, é uma realidade.

Sim, muita gente não sabe disso. Temos muito o que caminhar. Mas quem acompanha as listas de discussão (você AINDA não acompanha?), o planeta e principalmente acompanha os nossos eventos sabe que as coisas estão mudando. Pare para pensar como eram as coisas há 5 anos atrás?

Bom, ontem eu vi porquê valeu a pena esperar 3 anos para trazer o Bruce Momjian para o Brasil: em um dado momento ele contou um pouco da história do PostgreSQL e da sua história no PostgreSQL. De como ele começou a se dedicar ao projeto e de como aquilo inicialmente afetou a sua família e as suas finanças pessoais. Mas de repente, algo estranho começa a acontecer…. as pessoas começaram a utilizar o Postgres no Japão! Sim, em ambientes de produção. Estas pessoas criaram uma comunidade, com artigos, documentação, livros, profissionais qualificados e se tornaram o primeiro mercado a efetivamente utilizar o PostgreSQL para valer. A dedicação por anos de trabalho parece ter valido a pena.

Para mim isto tem um significado muito especial. Todos que me conhecem sabem que eu ainda não me sustento trabalhando com PostgreSQL. Mas já fazem alguns anos que eu tenho mantido algum tipo de contribuição para a comunidade brasileira. Sim, tem muita gente que começou muito antes e fez muito mais do que eu. Mas para mim e para muitos outros a questão é acreditar no projeto, acreditar nas pessoas. Cada vez que conheço um novo desenvolvedor do time central do Postgres eu fico mais empolgado. Pois são pessoas facinantes que estão desenvolvendo o Postgres. São pessoas que não são apenas desenvolvedores extraordinários. São pessoas com uma cultura e uma visão de mundo fantástica. É fantástico poder conversar com estas pessoas e saber que existem mais loucos pelo mundo. Que estes loucos fazem a diferença no mundo e que talvez você possa até fazer parte disso tudo, de dar a sua parte para construir um mundo mais próximo daquilo que você acredita que ele deveria ser.

YES, WE CAN!!!

IS DONE

IS JUST THE BEGINING…

Ok, devo postar mais sobre o evento, as fotos, as palestras, as pessoas, e outras coisas que rolaram no PGCon Brasil 2009, mas o dia já está claro e a água da piscina parece estar ótima…

As inscrições para o PGCon Brasil 2009 estarão abertas a partir de 16/09.

Garanta já sua inscrição!!!

Aproveite e baixe também o cartaz do evento aqui.

Eu estava interessado em conseguir uns 100 pendrives personalizados com o nome do PostgreSQL. Ano passado o David Fetter trouxe uns e eles evaporaram instantaneamente quando o pessoal ficou sabendo. Sim, eu tenho um.  Bom, o Josh disse que cada pendrive custava USD 8,00. Seria um pouco mais barato do que o preço aqui no Brasil, mas o Josh já me adiantou que só tem uns 50. Aí ele me disse algo interessante: “Me arranje algo melhor que simplesmente distribuir os pendrives para todo mundo que eu posso lhe conseguir eles de graça para você. E outra pessoa no canal deu a ideia: “Me mostre a sua melhor consulta SQL e ganhe um pendrive”.

O Josh parece que gostou da idéia e eu mais ainda. Aí comecei a rascunhar e pensar em como organizar isso. Pensei logo em algumas categorias para participar:

• Consulta ou script;
• Artigo;
• Artigo traduzido;
• História em quadrinhos;
• Estudo de caso;

A ideia é mais ou menos assim: sabe aquela consulta que você criou para verificar o desempenho do banco? Aquele script de backup que ficou bacana? Ou aqueles testes que você ficou de publicar em algum lugar o resultado? Ah… tem também aquele artigo em inglês que um monte de gente adoraria ler em português. Bom, acho que deu para pegar o espírito da idéia. Você manda para nós o seu material, tem grandes chances de ganhar o seu pendrive e a comunidade ganha material novo para colocar na Internet. Todo mundo acaba ganhando.

Vá na página do concurso “O elefante está entre nós” no site do PGCon Brasil 2009 e participe!

Sim, sim, é verdade! A grade oficial está no ar!!!

Vá lá dar uma olhada e me diga o que você acha…

Vou contar um pouco dos bastidores do evento:

• Foram ao todo 40 propostas na chamada de trabalhos;
• 2 Palestrantes internacionais convidados;
• 65 pessoas votaram nas propostas e disseram quais eram as suas prediletas;
• 3 pessoas na banca avaliadora fizeram a seleção final das palestras;
• 4 tutoriais aprovados;
• 3 palestras avançadas;
• 4 Hacker Talks (palestras para quem deseja conhecer e  contribuir com o código do PostgreSQL);
• 11 palestras normais;
• 12 Lithning Talks  (palestras curtas de até 5 minutos cada);
• 3 salas simultâneas.

Bom, outras novidades estão por vir, inscrições, concurso, patrocínios, divulgação, tudo a caminho. Até o final do mês o evento deverá estar com quase todos os detalhes fechados.  Em breve traremos mais detalhes… em breve!

Diante deste tipo de dificuldade, resolvi fazer esta pesquisa para ver se há algum produto que interessaria mais a comunidade e se teríamos pedidos suficientes para cobrir as despesas com isto.

Você pode chegar nesta situação quando era apenas uma matriz que abriu uma filial. O banco de dados ficava só na matriz e a filial acessa o banco de dados remotamente, via Internet, conexão via rádio, linha privativa, etc. O problema é que a conexão com a filial tinha a mania de cair e quando isso acontece é como se acabasse a luz. Se pensarmos numa empresa que utiliza apenas a conexão da Telefônica aqui em SP, dá para imaginar o desespero.

Então a solução ideal se chama replicação multimaster síncrona: você tem alguns bancos de dados, cada um em um local diferente. Cada atualização realizada numa das bases é automaticamente replicada para as demais e vice-versa. Qualquer base pode sofrer atualizações. Uma vez realizada, ela é visível instantaneamente em todas as bases. Se você der um rollback em uma transação, o rollback será realizado de forma idêntica em todos os nós. Ou seja, tem de garantir o ACID em todos os nós, como se estivesse em apenas um banco de dados. Existe um recurso no PostgreSQL que visa garantir este comportamento, ele se chama commit em duas fases e está disponível a partir da versão 8.1 do PostgreSQL. O commit em duas fases é muito importante por realmente garantir a consistência através de todos os nós. Ele não resolve problemas como o uso intensivo de SEQUÊNCIAS ou o a equivalência de um TIMESTAMP com precisão absoluta, mas resolve o problema de ter um commit ou rollback sincronizado em todos os nós. Deve-se entender que o Commit em duas fases é implemento como comandos SQL e não como uma aplicação. Portanto a sua aplicação tem de ser desenhada específicamente para utiliza-lo.

Há uma solução no universo PostgreSQL conhecida como PGCluster, que não utiliza o commit em duas fases mas faz a replicação multimaster assíncrona através de um serviço de balanceamento de carga e outro serviço de replicação. E vai além disso, se a comunicação com um dos nós cair, ele sincroniza o nó quando ele volta a se comunicar com os demais. Não é ótimo?

Sim, o PGCluster é uma ideia muito interessante, mas não como uma solução de banco de dados distribuído. Cada alteração no banco de dados dispara uma atualização em cada nós que precisa ser confirmada em um por um e depois da confirmação, liberada em todos eles. Isto significa que o que seria feito em X tempo em um único nó, será feito em  2XNL tempo onde N é o número de nós envolvidos na replicação e L é a latência da rede. Isto significa que se os nós não estiverem dispostos lado a lado numa rede local de alta velocidade, a perda de desempenho é absolutamente intolerável.

Mesmo que você utilize fibras ópticas de última geração para interligar seus servidores localizados em lugares distintos, você sofrerá com uma limitação: a velocidade da luz. Até que se prove ao contrário, nada viaja a uma velocidade superior a da luz, inclusive a informação. E nas idas e vindas do commit em duas fazes, a velocidade da luz começa a ser relevante. Ou seja, o PGCluster só é funcional como solução de alta disponibilidade, para servidores que ficam todos no mesmo CPD. Ainda assim há uma perda de performance considerável em cada atualização do banco de dados (nas leituras a distribuídas da carga propcia uma melhora de desempenho). Para encerrar o assunto, vale lembrar que o PGCluster é uma solução complexa de instalar (são no mínimo 3 nós + o balanceador de carga + o replicador), sua última versão foi lançada em 02/2008 e não é uma solução realmente bem aceita pelos desenvolvedores do PostgreSQL.

Sim o commit em duas fases pode ser utilizado com sucesso para bancos de dados distribuídos, mas para sincronizar apenas algumas operações e não a base inteira. Se você pesquisar bastante sobre o assunto, irá esbarrar em outras soluções:

• Houve algum tempo, se pensou numa forma nova para implementar uma replicação multimaster síncrona num projeto batizado como Slony II que rapidamente foi abandonado por ser considerado complexo demais e inviável na prática.
• O PGCluster II  é uma tentativa de implementar algo semelhante ao Oracle RAC, que também é uma solução de alta disponibilidade e exige que todos os nós fiquem no mesmo local (eles tem de compartilhar o mesmo storage). Pelo que consta o PGCluter II ainda não teve nenhuma versão oficial lançada e não sei se ainda tem algum desenvolvimento ativo.
• O Bucardo é uma solução já em produção, mas não é síncrona, ou seja, ela admite um atraso entre as atualizações em cada nó o que exige regras de resolução de conflito quando um mesmo registro é atualizados em diferentes nós. Ou seja, não garante nem tem como garantir o ACID. O Bucardo é indicado para sincronizar uma base principal com outras bases  com pouco volume de atualização, como no caso de forças de vendas que tem uma base isolada no notebook de cada vendedor.

Bom, mas então como resolvemos o problema das filiais??? Duas abordagens distintas:

• Resolva o seu problema com o link e mantenha todos os seus dados numa única base. Pode parecer besteira, mas ainda é a solução mais utilizada por grandes empresas que podem investir na redundância de links de alta velocidade e alta disponibilidade;
• Não integrar todos os dados em uma única base. Faça com que  cada filial tenha apenas uma fatia dos dados e ponto final. Uma variação mais eficiente é fazer com que uma chamada por informações que se encontram em outro servidor sejam desviadas  para o servidor correto. Isto se chama particionamento horizontal ou cluster shared nothing e é uma técnica bastante complexa, mas muito eficiente. Uma forma de implementar isto no PostgreSQL é utlizando o PL/Proxy do Skytools.

As duas abordagens podem parecer um tanto radicais para você? Bom, eu diria que 90% dos grandes bancos utilizam exatamente estas abordagens:  possuem cerca de 3 ou 4 sites (digamos que em SP, DF e PE) cada uma respondendo por todas as transações da sua região. Há um investimento pesado para conectar todos os terminais no site da sua região. Se você precisar de informações de um site em outra região, a conexão é desviada para o site correto.

Estas são as duas formas óbvias de encarar o problema: centralizar tudo numa única base, ou dividir logo todos os dados em bases isoladas. Isto é tudo o que você pode fazer sem ter que mexer na lógica da aplicação. No entanto, se você está disposto a mexer na sua aplicação, particularmente na modelagem desta, então existe sim um meio termo. A primeira coisa a se fazer é dividir as tabelas em partes conforme as regras de negócio para a sua atualização:

1. Tabelas que não são atualizadas ou que são atualizadas raramente: inclua aqui tabelas de parâmetros e coisas do tipo. Se você puder realizar as atualizações em apenas um local então você pode fazer com elas caiam no segundo caso:
2. Tabelas que são atualizadas apenas em um nó como a matriz e são consultadas por todas as outras filiais;
3. Tabelas onde cada filial é responsável pela atualização de apenas um punhado de registros, sendo que cada filial não pode alterar os registros da outra filial;
4. Tabelas onde cada filial deve poder atualizar qualquer registro da tabela, independente de qual filial seja.

• Tudo que estiver nos casos 1 e 2 podem sofrer uma replicação multi/master, que é um pouco menos complexa e possui algumas boas ferramentas para implementar como o Slony I e o Londiste. A ideia é simples, você atualiza as informações em uma única base e as informações são replicadas para os demais nós.
• Tudo que estiver no 3º caso deve ser modificado para cair no 2º caso através do particionamento de tabelas. Assim você divide uma única tabela em uma tabela pai e várias outras tabelas filhas, uma para cada filial. As atualizações só serão feitos na tabela relativa a filial onde ele está e as suas atualizações são replicadas para as demais filiais. O particionamento de tabelas no PostgreSQL é um pouco chato de ser feito (melhorou um pouco no 8.4 mas no 8.5 está prometida uma revolução), mas é bastante flexível, portanto, depois de particionar as tabelas, você cai numa situação onde a replicação master/slave pode ser aplicada novamente;
• Se você tiver o azar de cair no 4º caso , então você não terá outra alternativa senão utilizar o commit em duas fazes. Em geral, com uma boa modelagem você consegue fugir deste tipo de situação ao máximo, mas quando não for realmente possível, a ferramenta é esta. Note que nos casos 2 e 3, não estou falando de replicação síncrona. Se você realmente precisar de transações síncronas, com ACID entre todos os nós, o commit em duas fases é a sua única opção.

Como você pode perceber, não existe solução fácil. Mas, feliz são os desenvolvedores que criam suas aplicações já pensando neste tipo de solução. É claro que hoje se utiliza muito SOA, REST e outras tecnologias para trafegar informações entre aplicações. Outros se aventuram com o envio de TXT, ou XML para lá e para cá das mais diversas formas. Há ainda aqueles que criam uma teia de DBLinks para interligar as bases. Eu como DBA não sou especialista neste tipo de solução, mas acredito que elas sirvam para resolver outro tipo de problema. Um exemplo clássico seria a disponibilização de informações ou serviços de uma aplicação para outra aplicação diferente e não para a replicação de informações dentro de uma mesma aplicação. Trocar informações entre aplicações é muito diferente de replicar informações em bases distribuidas. A chave do problema sempre estará nas diferenças entre síncrono e assíncrono, e master/slave e multimaster.

Bom, eu acho que é só por enquanto. Se alguém conhecer outro tipo de solução que não seja baseada em nenhum dos casos aqui ou se tiver uma experiência que refute os argumentos que apresentei aqui, por favor deixe um comentário abaixo para trocarmos umas figurinhas, ok?

• Para saber mais sobre os diferentes tipos de Cluster e Replicação, veja neste blog o texto: Cluster != Replicação.
• Para saber mais sobre soluções de alta disponibilidade e balanceamento de carva, veja o texto da documentação oficial: High Availability, Load Balancing, and Replication

Vejam a nota oficial de lançamento em pt_BR.

Preencha a pesquisa agora aqui.

Mini FAQ

• Sim, vamos públicar o resultado no final.
• Não, não sei quando ainda, mas deve levar pelo menos um mês.
• Não, não vamos divulgar nomes de empresas e pessoas que preencheram a pesquisa.
• Sim, A chamada para a pesquisa foi divulgada hoje no site oficial da comunidade e é lá que vamos publicar os resultados em breve.
• Sim, você pode e deve divulgar a pesquisa para aquele seu cliente que você sabe que utiliza PostgreSQL.
• Sim, você pode e deve divulgar a pesquisa em sites, blogs, listas de discução, etc.
• Sim, vamos fazer uma pesquisa qualitativa com mas detalhes sobre casos de uso brasileiros. Em breve…

[Show as slideshow]

[View with PicLens]

Agora resolvi brincar com as enquetes. Não sei se vai vingar. Depende mesmo do número de pessoas que vão votar. Se tiver um número razoável, prometo ir atualizando por aqui.

Segue a primeira, que não poderia ser muito diferente. Em breve, algumas mais polêmicas devem se seguir. Aguardo os votos do pessoal.

Aí as novidades continuam. O método de escolha foi muito debatido na comunidade. Haviam duas propostas em pauta:

• Votação direta pelos membros da comunidade (ou inscritos nas listas). A votação garante que o evento vá de encontro com os interesses dos participantes o que é fundamental para a satisfação dos participantes.
• O uso de uma banca avaliadora composta por 3 pessoas respeitadas da comunidade. Em 2007 foram os Srs. Diogo Biazus e Euler Taveira. Em 2008 foram os Srs. Leonardo César, Dickson Guedes e eu. Em 2008 se chegou ao consenso de que uma comissão com número ímpar seria interessante para não haver empates e que deveriamos alternar as pessoas envolvidas nesta banca. Para 2009 escolhemos os Srs. Luis Fernando Bueno, Leandro Dutra e Fernando Ike. A vantagem de usar uma comissão é a simplicidade e agilidade do processo e a capacidade de balancear temas e garantir a qualidade, uma vez que são pessoas que conhecem bastante de PostgreSQL no Brasil. Uma coisa interessante da comissão é a possibilidade de trazer temas novos, evitando que as mesmas palestras se repitam todos os anos.

Na dúvida ficamos com os dois. Haverá uma votação on-line entre os membros da lista PGBR-Geral. Esta votação irá apontar para as palestras mais populares e os temas mais solicitados e então uma comissão avaliadora composta de 3 pessoas fará uma seleção final.

Mas ainda temos cartas na manga: se houver um número muito grande de propostas, abriremos uma exposição de painéis (cartazes explicativos que são pendurados nos corredores do saguão com a presença de seus autores), como é comum se fazer em eventos acadêmicos. Desta forma, poderemos contemplar a participação de mais pessoas. Mas esperem, o melhor fica para o final! Vamos repetir o clima animado no final do evento de 2008: os Lightning Talks vão voltar! Na última semana antes do evento estaremos abrindo as incrições (que vão até o final do primeiro dia do evento) para as apresentações relâmpago, com duração máxima de 5 minutos cada.

Então senhores, se você já está trabalhando há algum tempo com PostgreSQL, envie sua proposta. Se você tem várias ideias, mande várias propostas. Escolha o formato mais adequado e mande para nós. Há inúmeros temas que você pode abordar. Este ano teremos mais espaço, 2 auditórios e uma sala VIP, então vale a pena compartilhar conosco um pouco da sua experiência. Você não precisa ser um gênio, basta apenas ter testado alguma coisa interessante e chegado a alguma conclusão no caminho. Muita gente acha que não tem nada de interessante para falar… eu digo que ao acompanhar a lista, tem um montão de gente respondendo e-mails que eu adoraria ver subir no palco e dividir um pouco mais do que sabe conosco. Vejo um zilhão de dúvidas que se repetem e dúvidas que mereciam um tutorial inteiro para explicar melhor como fazer.

Se você está realmente sem idéias, eu vou dar algumas (tem muuuuito mais, claro!) sugestões:

• Técnicas para carga de grande volume de dados e ETL;
• Desempenho, segurança e uso de Discos e Sistemas de Arquivos;
• Testes com novos sistemas de arquivos como EXT4, ZFS, quem sabe BTRFS…
• GUCs e dicas de configurações de parâmetros;
• Segurança de aplicações usando PostgreSQL: técnicas para autenticar usuários e evitar SQL Injection;
• Uso de Full Text Search;
• PostGIS;
• Uso de PostgreSQL em aplicações de suporte a decisão (BI);
• Técnicas de Backup físico e lógico, ou melhor: técnicas de restauração!
• Como encontrar SQLs lentos e reescrevê-los;
• Como monitorar o uso de recursos com as novas funções, visões, opções de log e ferramentas do PostgreSQL;
• Como criar índices realmente úteis e remover índices inúteis;
• Utilizando técnicas de replicação multimaster assíncronas;
• Comparação de diferentes técnicas de replicação: onde eu uso o que?
• Tudo que você queria saber sobre internacionalização e localização e tinha vergonha de perguntar;
• Refatoração de banco de dados sem perder a cabeça ou o emprego!
  
• Migração para PostgreSQL (a partir de Oracle, MySQL, DB2, SQL Server, o que for);
• Versionamento de banco de dados: gerenciando a mudança com responsabilidade!
• Técnicas de auditoria e monitoramento de usuários;
• Desempenho com responsabilidade: descubra o ponto G do PG…
• Casos de sucesso, sim, queremos saber quem está usando o PostgreSQL por aí!
• Casos de insucesso e dicas para evitar entrar em grandes roubadas. Tambem poderia ser: “Eu não disse que esse negócio de banco de dados livre não prestava…” (fala sério, alguém tem que fazer esta um dia)
• Conhecendo um pouco do código fonte do PostgreSQL e funções SPI;
• Ferramentas para modelagem e documentação de DDL para PostgreSQL (tem alguém me devendo essa)
• 10 Coisas que ainda não funcionam bem no PostgreSQL,mas que estão em vias de se resolver (ou não) e como contornar estes problemas;
• Os desafios em ambientes transacionais pesados e com grande volumes de dados;
• PostgreSQL em aplicações científicas. Em 2008 aprovamos uma palestra de banco de dados para dados biológicos que cancelou na última hora, uma pena.
• Modelagem utilizando tipos, vetores, domínios, funções de agragação e outros bichos;
• Consultas recursivas com Common Table Expressions;
• Cálculos complexos com Windowing Functions;
• Stand By rápido e rasteiro.
• A caixa de ferramentas do DBA: consultas e formas de se trabalhar para tornar a vida do DBA mais simples e produtiva;
• Os 12 pecados do desenvolvedor que começa a utilizar o PostgreSQL pela primeira vez;
• PostgreSQL para adminstradores de sistema: montando um servidor seguro, rápido e fácil de administrar;

Bom, estas são apenas algumas sugestões, existem várias outras que não pensei agora. Sugestões? De qualquer forma, estamos muito querendo ver novas caras do PGCon Brasil este ano, agora é só escrever e mandar.

Senhores, eu sei que muitos que estão utilizando o PostgreSQL são novatos, estudantes e entusiastas. Sei que não é de bom tom tratar estas pessoas de forma seca e dura, pois são pessoas que futuramente vão apoiar a comunidade e utilizar o PostgreSQL em cenários mais sérios e coisa e tal. Mas hoje me deu os 5 minutos de fúria.

Vamos escrever melhor gente? Eu seu que não sou uma pessoa que contribui ativamente aqui na lista. Não respondo muita coisa. Mas venhamos e convenhamos, o nível das perguntas (e muitas vezes das
respostas e comentários também) desanima qualquer pessoa letrada que se esforça para se comunicar adequadamente.

Antes de disparar com a metralhadora para todos os lados, eu quero
dizer: entendo que os erros de ortografia e de digitação fazem parte da nossa vida. Eu mesmo cometo erros terríveis no meu blog e nos e-mails. A língua portuguesa é chata mesmo. Quando estou ajudando o
meu filho de 6 anos a fazer a lição de casa eu percebo como as regras
são confusas: G e J, c, ç, ss, z ou c e q, m ou n, r ou rr, e por aí vai. Mas inventaram os corretores ortográficos e eles estão aí para nos livrar da peste, da fome e da danação.

Proponho lançar uma campanha de 5 pontos aqui (a exemplo de zilhões de campanhas semelhantes em trilhões de listas por aí):

1. O nome do banco de dados livre mais avançado do mundo é ‘PostgreSQL’ ou simplesmente ‘postgres’. Sim, você pode escrever sem acentos e sem letras maiúsculas. Pode até abreviar para PG numa lista mais informal como a nossa. Mas não use nenhuma outra forma, ok? É como mandar um cartão de dia dos namorados com o nome da garota escrito errado. Na dúvida repita em voz alta para não errar mais:  postgres, postgres, postgres. Dá um bom mantra, é relaxante, tente novamente: postgres, postgres, postgres…
2. Guarde o miguxes para os seus amigos do tempo do ensino fundamental. Se você escreve ou até fala assim, guarde este segredo terrível para você e aqueles que praticam isso. Não abrevie palavras como se estivesse num chat e principalmente não utilize expressões escritas propositalmente erradas. Conheço muita gente da velha guarda que sente dificuldade em ler menssagens assim. O resultado? Não respondem. Eu não respondo mais e sei de gente muito boa que também não responde.
3. Descrevam o problema! Gente, nós não conhecemos o seu ambiente, não vemos os erros que estão acontecendo na sua tela e não sabemos o que você fez. Nós não vamos adivinhar se você não contar. Dizer simplesmente: “estou com um problema no postgres e nada funciona aqui” pode conter o nome do banco de dados escrito corretamente, pode até fazer um bom uso da língua portuguesa, mas não nos diz nada. Se você se sente apenas frustrado e quer desabafar, recomendo uma boa cerveja, ver desenhos animados na TV ou até mesmo conversar com alguém no IRC. Mas dizer que não funciona e não citar o contexto não vai lhe ajudar.
4. Se o seu chefe/professor mandou você fazer um trabalho com PostgreSQL para ontem e você precisa de alguém que faça uma parte do trabalho para você, a lista será um ótimo lugar para você encontrar um profissional que lhe cobrará um preço justo pelos seus trabalhos. Não, não vamos fazer o trabalho de graça por você. Por favor não peça.
5. Uma boa pergunta é metade do caminho para encontrar a resposta. Se você leu a documentação, pesquisou na Internet, testou e não conseguiu fazer o que você queria, você deve ter uma dúvida. Gaste um tempo na elaboração da pergunta. Pense um pouco.
   • Se você leu um monte de documentações (principalmente a oficial) e não entendeu nada, seu problema é de compreensão de texto. Estude inglês ou português e principalmente leia mais. Um livro por mês seria uma boa meta para você. Mas pelo menos 2 bons livros por ano é o mínimo que um cidadão alfabetizado deveria se habituar a ler. Revistas em quadrinhos são muito legais (eu adoro) mas não contam aqui.
   • Se você testou vários how-tos e receitas de bolo prontas e nada funcionou, vá ler a documentação oficial antes de sair perguntando. Um bom tutorial sempre tem referências. Leia as referências. Ocorre que um tutorial se refere a uma situação específica. Pode não ser o seu caso. Você pode precisar de adaptações. Para quem tem uma boa base de conhecimento (por exemplo, para quem leu a tal da documentação…) o tutorial é muito interessante. Para quem cai de paraquedas, costuma ser um desastre.
   • Se você pesquisou um bocado e leu um bocado e conseguiu evoluir até um certo ponto e depois travou. Você deve ter uma genuína dúvida. Mande um e-mail para nós. Escreva bem, descreva o seu processo e nós lhe ajudaremos. Mas antes de enviar o e-mail, lembre-se que você gastou um tempão para chegar onde está. Se você souber exatamente o que você não está entendendo e souber materializar sua dúvida em forma de um texto, seu problema estará muito próximo da solução. É muito comum se passarem 5 ou 10 e-mails numa lista até que as pessoas entendam precisamente o que você quer saber. Pergunte bem e você terá uma boa resposta. Mais que isso, você será respeitado pelo seu esforço em pesquisar antes e também pela sua capacidade de elaboração de questões relevantes.

Há alguns anos atrás, quando o PostgreSQL começou a ganhar mais visibilidade no Brasil (no lançamento do PostgreSQL 8.0 para ser mais exato), houve uma grande tensão na lista por causa da invasão dos miguxos, analfabetos digitais e até folgados mesmo que caiam diariamente de paraquedas na lista. Eu não acho que espantar esta turma nos ajudará em alguma coisa. Mas se as pessoas vem à lista para aprender alguma coisa, espero aqui estar dando a minha contribuição pedagógica. Sim, eu sou um brasileiro e não desisto nunca!

Bom, apesar de não ter contribuído com a organização, eu acabei aceitando o convite feito no próprio PGCon 2008 de ir para Rondônia. Então eu e o Sr. Euler Taveira fomos de avião para lá. O Sr. Euler, diga-se de passagem virou arroz de festa e está indo a quase todos os PGDays. Só não vai para SC por um motivo simples: vai estar no canadá no PGCon internacional nesta data.

Cada evento traz consigo características próprias: em DF, o Sr. Jair Silva mostrou um pouco do mega ambiente corporativo da Caixa Econômica Federal utilizando PostgreSQl e houve também um longo tutorial sobre replicação com o Sr. Dickson Guedes. Em SP, foram 6 palestras com a grade mais diversificada até o momento. Em RO, foi o maior público até agora. Não tenho os números ainda, mas se juntarmos os dois dias de evento em Porto Velho e Ji Paraná certamente contaremos com algo na casa das 300 pessoas. No RS temos uma renovação nos palestrantes, tendo 3 pessoas que não palestraram em nenhum PGCon Brasil na grade. Por fim, teremos o PGDay SC que ainda não tem a grade fechada, mas é o primeiro a estrear um sistemas de inscrições integrado no próprio site da comunidade.

Enfim, muita coisa boa rolando. O povo do FISL 10 já avisou que quase todas as propostas de palestras sobre banco de dados são para PostgreSQL. Não é muita novidade para nós… ano passado também foi assim. De qualquer forma, eu diria que a comunidade tem realmente se destacado nos últimos tempos.

Meus parabéns a todos os organizadores!

Não achou nenhum link? Tudo o que você quer saber sobre eventos da comunidade brasileira de PostgreSQL está aqui.

• Apesar do fiasco da campanha “Adote um artigo sobre PostgreSQL“, a nossa página wiki internacional conta hoje com 14 artigos. É pouco, mas já é alguma coisa. E agora é oficial, os artigos em pt_BR vão ficar lá mesmo. Espero que com o tempo nós tenhamos novos ótimos artigos por lá;
• O novo site feito em Drupal 6 finalmente ficou pronto. Sim, temos um novo site em http://www.postgresql.org.br com novo visual, novas funcionalidades, novo conteúdo e nova dinâmica de atualização. Você também pode contribuir com novos conteúdos, basta se cadastrar e escrever. Tenho aqui que agradecer os esforços de muitos que ajudaram nesta empreitada, particularmente o Nei Rauni Santos, Dickson Guedes, Felipe van de Wiel e Athur Furlan. Devagarinho,  nosso Webmastar Guedes está adicionando novas funcionalidades. Longa vida ao site!
• 5 PGDays espalhados pelo país ocorrendo entre abril e maio deste ano. DF, SP, RO, SC e RS. Não é mole não… o povo está se mexendo e as coisas estão acontecendo.  O primeiro a acontecer foi o de Brasília com mais de 100 participantes em um dia repleto de palestras. Esta semana é a vez de São Paulo e na semana que vem eu vou para Rondônia que terá um PGDay em duas cidades: Porto Velho e Ji Paraná. Já tomei minha vacina contra febre amarela e vou lá finalmente conhecer de perto o povo que usa o PostgreSQL para salvar a Amazônia!
• A organização do FISL 10 já começou. O nosso wiki onde estão os documentos relacionados a nossa organização interna já tem uma página com algumas das palestras que estão sendo propostas para o nosso evento comunitário lá.
• A organização do PGCon Brasil 2009 também está andando. Espero que até o final do mês o site do evento já esteja no ar também. Enquanto isso a captação de recursos já está a mil por hora, graças ao nosso reforço do Fernando Ike.
• Eu recebi nova incumbência este ano. Na última reunião da comunidade eu assumi a tarefa de cuidar da prestação de contas e tesouraria do PGCon Brasil 2009. Tarefa trabalhosa, uma vez que quem me conhece sabe como sou exigente quando se fala em transparência.
• E por fim a maior de todas as novidades, saiu o Beta1 do PostgreSQL 8.4!!! Sim, sim, podemos aguardar uma nova versão em breve. Eu já estou testando ele por aqui e posso garantir que tem muita coisa boa pela frente. Mas isto, é assunto para outro longo post.
  

E assim como o Yahoo se negou a ser comprado pela Microsoft (por cifras astronômicas em tempos pré crise), a Sun parece ter não gostado muito da oferta da IBM e aceitou uma oferta ligeiramente superior da Oracle. E zilhões de dúvidas vem a cabeça. E agora o que serão dos projetos livres da Sun? Java, OpenOfficce, MySQL, Solaris e por aí vai. Ninguém sabe… mas a primeira coisa que percebemos é que o mercado corporativo de TI vai se afunilando entre gigantes como IBM, Microsoft, HP, Dell e Oracle. Mas seria bom dar uma olhada na Oracle um pouco mais de perto.

• A Oracle surgiu como um dos primeiros SGDBs relacionais do mercado, logo depois do DB2 da IBM. Se é verdade que o DB2 ainda dita a maior parte do padrão ISO SQL, a Oracle já lidera claramente este mercado há alguns anos;
• Se é verdade que até a década de 90 a Oracle se firmou no mercado como desenvolvedora do maior banco de dados do mercado, também é verdade que ela virou a mesa e tem hoje uma suite completa de soluções de grande porte:
  • SO com o clone o Red Hat, o Unbreakable Linux,
  • Banco de dados com o Oracle Database, e também o InnoDB,  o Berkeley DB, Times Ten
  • Middleware com o Oracle Application Server, SOA Suite, Weblogic, Content Management, etc;
  • ERP com o JD Edwards, People Soft, Siebel, E-Business Suite, etc;
  • Monitoramento com o Oracle Enterprise Manager;
• Se por um lado a Oracle tem uma política de licenciamento que lhe cobra por uma base de testes, um stand by e possui inúmeras funcionalidades e parâmetros não documentados nos seus produtos, oferece o download livre para qualquer um baixar e testar seus produtos e uma enorme biblioteca de documentação pronta para baixar e imprimir, em versão PDF ou HTML.
• Sim, a Oracle investe em Software Livre sim. Tem inclusive um portal para isso, o http://oss.oracle.com/ com projetos como o OCFS2 e o Btrfs, dois poderosos sistemas de arquivos. Além disso, a Oracle tem uma contribuição intensa no kernel do Linux já faz um bom tempo.
• Sim, a Oracle tem uma política monopolista e compra tudo que está a sua frente. Mas ao contrário de querer dominar a Internet, como a Microsoft e o Google, o foco da Oracle é bem claro: soluções corporativas para grandes empresas. E diga-se de passagem, ela tem crecido numa velocidade incrível neste segmento. Porém, se a excelência de suas soluções em banco de dados deram uma fama de competência e confiabilidade em seus produtos, o mesmo não se pode dizer sobre as suas demais aplicações que rodam sobre o seu banco de dados. O Oracle Aplication Server é uma colcha de tecnologias livres empacotadas como um monstro de várias patas e nenhum cérebro. E vai a Oracle já avisando que depois de abandonar o terrível Forms e Reports, vai abandonar o fiasco do OAS também em função de uma plataforma Java melhor… é esperar para ver. Os seus ERPs também não são a oitava maravilha em termos de tecnologia (ALGUM É)???? O PeopleSoft por exemplo não tem uma única chave estrangeira no banco de dados, fazendo toda a integridade referencial dentro da aplicação. Não é bem o que a Oracle sempre pregou nos seus manuais.
• O suporte da Oracle é muito eficiente, funciona 24/7 de verdade. Podem lhe atender no Brasil, EUA, Japão, Índia ou onde quer que seja necessário para atendê-lo em qualquer horário. Mas veja: o nível básico de suporte (independente no nome bonito que se dê)  por e-mail, dá um trabalhão para abrir um chamado. Uma das coisas mais irritantes no site de suporte da Oracle é que eles utilizam tecnologia da Oracle para montar o portal web. É horrível, quem está acostumado com o Gmail e outras interfaces cheias de Ajax como o Wordpress sabe o quão terrível é o metalink da Oracle. Fizeram uma versão nova com uso de Flash… piorou!

Então se por um lado a Oracle tem tradição com Software Livre, não tem foco em produtos na linha do MySQL e do OpenOffice. É claro que se é para minar a concorrência com a Microsoft pelo mercado de médio porte, pode não ser má idéia investir um pouco neles, mas não acredito que será o foco principal deles. É claro que podem surgir estratégias inovadoras junto ao MySQL… ele pode se tornar mais aberto ao Oracle e virar um novo Times Ten, mas não acho que vai perdes suas características atuais. Manter o Marketshare do MySQL, apesar de não trazer muito lucro será muito bom para a Oracle que pegará duas pontas do mercado. Já o Solaris o Java são com certeza algo de interesse por parte da Oracle. Veja que o Btrfs que a Oracle criou é baseado no ZFS que por problemas de licenças da Sun, não pode ser agregado ao Linux que usa GPL. Daí se vê a preocupação da Oracle com algumas boas tecnologias encontradas no Solaris. O Java então… toda a suite que roda sobre os bancos de dados Oracle usa Java. Isso sim é um tiro certeiro. Já os servidores SPARC são bons competidores para os servidores da HP e IBM. São caros, mas tem um mercado cativo ainda bem definido em soluções de grande e médio porte.

Mas temos um perdedor claro aqui: o PostgreSQL que vinha sido apoiado pela Sun está certamente fadado a perder esta condição. É claro que existem outras e muitas outras empresas apoiando. Mas a ausência da Sun será sentida, com certeza.

OBS: O artigo do Peter Eisentraut é bem interessante. Acho que concordo com quase tudo que ele diz. Vale a pena dar uma olhada lá.

Vale lembrar, que dois dos stogages engines que o MySQL utiliza o Berkeley DB e o Inno DB já pertencem a Oracle. A diferença é que o MySQL seria utilizado como uma porta de entrada para o Oracle Database, substituindo parcialmente o engine do Times Ten In-Memory Database. Assim, o MySQL poderia continuar funcionando como um banco de dados stand alone ou poderia ser um “cache” do Oracle, de forma transparente para a aplicação.

Há rumores também de que a Oracle estaria interessada em comprar da SUN os direitos sobre toda a plataforma Java. Não foram citados números para a transação até agora. Mas vale lembrar que a SUN comprou a MySQL AB por 1 bilhão de dólares no ano passado. Isto não parece problema para uma empresa que comprou nada menos que a People Soft, a BEA, Siebel entre outras, somando aportes de recursos fantásticos em investimento.

Realmente hoje é um dia divertido. Eu ia inventar que a Oracle queria comprar a Red Hat, mas achei que não seria tão verossímil, até descobrir que este rumor existe de verdade. Ok, seria muito mais divertido se eu soubesse fazer algo como peguins voadores!

O pessoal da sala ao lado é o que nos dá menos problema. São nossos melhores usuários.

Chefe de TI de um hospital, cujo CPD fica ao lado do necrotério!!!

Isto já era notável na diferença entre a FENASOFT e a CONDEX na década de 90. Menos gente é sinônimo de platéia mais selecionada e mais Whiskey nos estandes. De qualquer forma, o recém adquirido hábito de utilizar gravata parece ter me beneficiado ontem.

Apesar de ter encontrado alguns conhecidos, foi sozinho que eu consegui aproveitar mais o evento. Só pude ir em um dia, cheguei cedo, saí tarde, assisti palestras e passei um bom tempo nos estandes conversando com o pessoal. Já que estão pagando para mim, melhor aproveitar ao máximo.

Os estandes estavam distribuidos mais ou menos assim:

• Grandes marcas como IBM, SUN, HP e Dell
• Prestadores de serviço como DBAs
• Consultorias para implantar sistemas ERP, CRM, etc;
• Fornecedores de soluções que rodam em ambiente oracle (banco de dados, servidor de aplicação, etc);

Bom a primeira coisa notável é que não haviam estandes enormes. A SUN e a HP estavam quase escondidas e stands modestos, por exemplo. A segunda coisa é que se Oracle era sinônimo de banco de dados para você, esqueça. O banco de dados é apenas a ponta do iceberg na cadeia de produtos e serviços da Oracle. A Oracle tem se notabilizado por uma agressiva estratégia de aquisição de empresas e tem soluções de todo tipo: SGDB, ERP, BI, SO, CRM, SOA e mais uma tonelada de letrinhas e buzzwords. E o banco de dados é apenas uma dentre os vários produtos e isto tinha reflexo também na ocupação da grade do evento do espaço de exposições dos estandes. Sobre os diversos produtos e camadas que a Oracle tem para rodar, acima do banco de dados eu só tenho uma coisa a dizer: eu gostaria muito delas se elas seguissem as recomendações da própria Oracle nas suas documentações.

Bom, fora isso vi algumas coisas bacanas. Algumas coisas que me chamaram a atenção:

• Palestra sobre backup/recovery mostrando inclusive o novo assistente para recuperação de desastres. Nota: cada vez mais eles querem empurrar o ASM e o RMAN. Eu sei que estas tecnologias são interessantes, mas são todas no estilo ame-o ou deixe-o.
• O Oracle TimesTen é uma tecnologia muito interessante, que mostra como a Oracle consegue ser inteligente e por isso mesmo cruél. A tecnologia funciona como um banco que guarda tabelas de um banco tradicional em memória e fica como uma camada na frente aceitando consultas da aplicação. Muito rápida a solução, aceita SQL92 e funciona com vários fornecedores de SGDB. A Oracle comprou a empresa que desenvolveu isso. Agora o TimesTen é orientado apenas para o SGDB da Oracle, custa muito mais caro do que antes e só funciona com a versão Enterprise. É mole?
• A HP e a Oracle mostraram um rack 44U com várias gavetas de storage, 4 servidores em RAC ligados por vários canais Infiniband. A novidade era um software da Oracle que filtrava os dados pelos  predicados (leia-se aqui como clausula WHERE ) da consulta em nível de hardware, diminuindo o fluxo de dados. Um monstrinho otimizado para BI. O detalhe é que o software da Oracle só funciona com aqueles discos, aquelas controladoras, aqueles switches infiniband, aqueles servidores HP e montados naquele rack.

Depois disso eles ainda chamam isso de Open World?

Em tempo, fui olhar um poco das tecnologias de Storage por lá… algumas novidades na área sim. Mas isto fica para outro dia.

Em 2009, para a nossa felicidade, teremos novamente 2 palestrantes brasileiros no evento.

• O Sr. Euler Taveira, com a palestra pg_similarity, Functions and Operators for Executing Similarity Queries

• O Sr. Luis Bueno, com a palestra Saving the Amazon with PostGIS, Spatial Manipulation in the Rain Forest

Como se vê, o Brasil continua sendo muito bem representado. Boa sorte Euler e Luis nas suas palestras. Bom evento para os demais brasileiros que tiverem a sorte de ir acompanhar o evento.

Para quem não pode ir para tão longe, não se desanimem, teremos eventos regionais chamados de PostgreSQL Days em vários estados do Brasil ocorrendo possivelmente em abril e maio e o nosso PGCon Brasil confirmadíssimo para os dias 23 e 24 de outubro na Unicamp, Campinas – SP.

A questão é simples, ao invés de manter uma seção de artigos sobre PostgreSQL no site da comunidade, estamos adotando uma nova estratégia: centralizar tudo no WIKI da comunidade internacional em http://wiki.postgresql.org. Todos os artigos em inglês estão agora por lá. E tem mais, artigos em outras línguas também. Já existem sessões dedicadas ao francês, espanhol, alemão, japonês, chinês e agora abrimos uma área para o português. Colocamos pouca coisa lá até agora, mas você pode ajudar, e muito.

O que você precisa fazer para adotar o artigo:

• Escolher um artigo. Você pode escrever um artigo novo ou escolher um  já existente. Em tese, você poderia escolher qualquer origem para o artigo que você vai adotar: pode ser um artigo num blog, como os vistos no nosso Planeta PostgreSQL Brasil,  pode ser um artigo da nossa sessão de artigos (que será desativada em breve) em http://www.postgresql.org.br/Documentação, pode ser uma apresentação em um evento, pode ser um artigo em outra língua que você vai traduzir, pode até ser um artigo de uma revista.
• Procurar descobrir o autor e a licença de compartilhamento do artigo. Este é um ponto importante. Antes de sair copiando e alterando qualquer coisa, tenha certeza de que você pode fazer isso. Existem inúmeras licenças utilizadas em artigos. Algumas permitem apenas a cópia sem alteração, outras permitem alterações no documento, mas você é obrigado a citar o autor, manter a mesma licença ou não fazer uso comercial. Se você não encontrar uma licença explícita no artigo ou site onde você encontrou o artigo, procure entrar em contato com o autor e pedir a sua autorização. O autor costuma se sentir sempre lisonjeado e tende a colaborar;
• Verifique se o artigo está muito ultrapassado e procure atualizá-lo. Se possível coloque obervações onde uma versão anterior do PostgreSQL funcionava diferente. Se a licença não permitir alterações, faça um preâmbulo ou alguma citação que mostre a data do artigo e para qual versão do PostgreSQL o texto se aplica;
• Correções ortográficas são sempre bem vindas, mas procure não mexer no estilo literário do autor, se julgar necessário, escreva um novo artigo e cite o artigo anterior como fonte de inspiração;
• Coloque sempre o nome do autor, a origem do artigo (se possível com o link), a licença em que o artigo foi publicado e o nome do revisor/tradutor no final do artigo.
• Procure sempre inserir o artigo diretamente no Wiki ao invés de criar um link para o artigo. Procure também utilizar uma formatação consistente com o artigo original;
• Não utilize processadores de texto como o Microsoft Word ou o BROfficee para editar o artigo, prefira sempre um editor de texto puro;

ATUALIZAÇÃO IMPORTANTE:

O Wiki do PostgreSQL adota por padrão a licença BSD, conforme descrito no seu documento sobre Copyrights. Ou seja, o autor deve concordar em disponibilizar seu artigo sob esta licença, que é a mesma do software PostgreSQL e sua documentação. Em último caso, se você não puder alterar a licença, você pode adicionar apenas um link no Wiki para outro local onde o artigo está publicado.

No mais tudo funciona como em qualquer Wiki que você encontra por aí. Incluindo o esquema de criação de contas, edição e rastreamento de alterações. Você também pode a qualquer momento alterar, ampliar ou corrigir um artigo já publicado (quando a sua licença o permitir).  Note que o uso do Wiki para guardar documentações não é de forma alguma casual. O software é livre, a documentação é livre, os artigos são livres e toda a plataforma web onde isto é disponibilizado também!

Bom, se você queria uma forma de contribuir com o PostgreSQL, mas achava que não tinha conhecimento técnico ou tempo suficiente para ajudar, chegou a sua vez. Que venham novos artigos!