Hora de considerar a versão 9.1?

Ao ler o post do Greg, resolvi apresentar a minha opinião sobre o $TITULO. É bom ser cauteloso quando estamos lidando com nossos dados. Mas será que devemos esperar quanto tempo antes de considerar uma atualização para uma versão mais nova?

Quando estamos lidando com versões antigas de uma tecnologia sempre nos deparamos com desenvolvedores de aplicações que estão tentando utilizar as últimas funcionalidades que o software oferece. No universo do PostgreSQL, isso não é diferente; há sempre uma nova função, uma sintaxe diferente, a otimização de um tipo de consulta, um novo tipo de índice e por aí vai.

Além disso, os DBAs enfrentam no dia-a-dia as limitações de uma versão que vai se tornando obsoleta ao longo dos anos (tenho clientes utilizando a versão 8.1 e que ainda sofrem dos picos de escrita durante o checkpoint). Os DBAs são os profissionais mais cautelosos dentre aqueles que administram serviços; mesmo assim, consideram atualizar entre versões para (i) diminuírem a dor de cabeça com as limitações pré-existentes e (ii) beneficiarem das novas otimizações e oportunidades (de ajuste e monitoramento).

Voltando a questão da versão, o PostgreSQL sempre considera novas versões aquelas que mudam o X e/ou Y em X.Y.Z (o Z é reservado para correção de bugs). Assim, os primeiros lançamentos das novas versões são 7.4.0, 8.0.0, 8.1.0, 8.2.0, 8.3.0, 8.4.0, 9.0.0, 9.1.0 (preferem omitir o .0 pois afinal de contas, uma vez na versão X.Y os binários podem ser atualizados para Z+n sem precisar fazer uma migração entre versões -- cópia de segurança -> restauração ou pg_upgrade). Dentre os lançamentos mencionados há uma diferença: aqueles que mudam o X e os que não mudam. É uma diferença na qualidade? Não. A mudança no X ocorre quando há um grande número de funcionalidades impactantes em uma nova versão com relação as anteriores. Foi assim da 7.4 -> 8.0 (suporte a Windows, tablespaces, PITR, savepoints) e da 8.4 -> 9.0 (replicação embutida, Hot Standby, bloco de código anônimo aka DO).

Olhando do ponto de vista de evolução de um software, mais mudanças código geram mais bugs! Então para aqueles DBAs mais cautelosos eu não aconselho que migrem rapidamente quando o X mudar. Costumo aconselhar que esperem alguns lançamentos de versões de correção (talvez 3 ou 4) para pensar em adotá-las. Quando quem muda é o Y, o conselho é esperar 1 ou duas versões de correção. Geralmente, logo após o lançamento de uma versão (como foi o caso da 9.1 recentemente), o grupo de desenvolvimento lança versões corretivas pouco tempo depois para corrigir aqueles bugs que passaram despercebidos durante o longo ciclo de testes (beta e RC -- 6 meses).

Como estamos na 9.1, se você estiver considerando uma atualização de versão, faça um planejamento com a 9.1 ao invés da 9.0 (por exemplo). Apesar de ser uma nova versão, o tempo que as suas aplicações ficarem em teste é exatamente aquele em que o grupo de desenvolvimento terá lançado 1 ou 2 versões corretivas.

Seja feliz com 9.1 até que o 9.2 ou 9.3 saia do forno e você considere atualizar novamente. ;)

9.1 beta 1 foi lançado

O Grupo de Desenvolvimento Global do PostgreSQL lançou a primeira versão beta da série 9.1. Esta versão (beta) é uma prévia do que será lançado possivelmente daqui a um ou dois meses. Quanto mais gente testar as versões beta mais estável será a primeira versão da série 9.1. Os benefícios de testar o 9.1 não param por aí. Você poderá testar as novas funcionalidades em primeira mão e verificar se houve alguma regressão de funcionalidades existentes (utilizadas pelas suas aplicações).

Vale lembrar que:

• como alguns produtos comerciais, o PostgreSQL lança uma versão nova a cada ano, como temos feito nos últimos sete anos;
• a versão 9.1 terá mais funcionalidades importantes do que as últimas três versões. Enquanto isso, os outros SGBDs têm lançado somente consolidação das funcionalidades já existentes;
• a versão 9.1 terá várias funcionalidades cujo PostgreSQL será o primeiro SGBD (de código aberto ou proprietário) a suportá-las.

Assim, é bom lembrar que não é só os SGBDs noSQL que podem inovar e/ou avançar rapidamente. O PostgreSQL tem estabilidade e é capaz de inovar também. O tema desta nova versão reflete justamente o que foi (aproximadamente) esse ano: Funcionalidades, Inovação e Extensibilidade.

Uma prévia das principais funcionalidades está abaixo. Para uma lista completa, consulte o manual.

Funcionalidades

• replicação síncrona: criar bancos de dados em espera síncronos para previnir perda de dados. Inclui a efetivação (COMMIT) síncrona controlada pela transação;
• collation por coluna: bancos de dados multilíngues podem ser criados, onde cada coluna pode ser de uma língua;
• tabelas sem durabilidade (unlogged tables): uma alta taxa de escrita para dados efêmeros como tabelas de sessões;

Inovações

• busca por k-vizinhos-próximos: mecanismo de indexação para acelerar buscas do tipo "quais são as k pizzarias mais próximas". Isso ajudará muito as aplicações espaciais (spatial applications);
• isolamento de instantâneo serializável: suporte a serialização com transações concorrentes e complexas, prevenindo condições de corrida e impasses (deadlocks);
• writeable common table expressions: execução recursiva de atualizações e outros mudanças de dados em um só comando SQL;
• SE-Postgres: é o único SGBD que oferecerá integridade total utilizando o framework SELinux.

Extensibilidade

• extensões: manipular as extensões (módulos adicionais) do PostgreSQL com facilidade (utilizando comandos). Uma rede online (PGXN) de extensões facilitará o gerenciamento e obtenção das extensões;
• SQL/MED: anexar outras fontes de dados (arquivos, outros SGBDs, streams) ao PostgreSQL e usá-las como tabelas.

Para que o lançamento da versão 9.1 seja rápido, precisamos que muitas pessoas testem e atestem que ele está funcionando adequadamente. Se você poder testar, leia o HOWTO de como testar e relatar a experiência com a versão 9.1. Reportem os sucessos e também os fracassos.

Binários estão disponíveis e também o código-fonte.