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. ;)

palestras para PGBR 2011

Esta semana encerra o prazo para o envio de palestras para o PGBR 2001 que acontecerá nos dias 3 e 4 de novembro em São Paulo, SP. Não deixe de enviar a sua proposta de palestra!

As palestras podem ser básicas ou avançadas, curtas (palestra) ou longas (tutorial), português, espanhol ou inglês. Só há um pré-requisito: ser relacionada ao PostgreSQL.

Todos os palestrantes terão entrada gratuita.

Vá a página de submissões de trabalhos e envie-nos as suas propostas! Você pode submeter até 5 ideias interessantes. Não deixe de divulgar esta nota para outras comunidades relacionadas; talvez alguém tem uma ideia interessante por lá.

Te espero no PGBR 2011.