PostgreSQL depois das atualizações de agosto: corrigir seis linhas sem misturar Beta e produção

O sinal e os factos que mudam a decisão

O PostgreSQL Global Development Group publicou em 13 de agosto as versões 18.6, 17.11, 16.15, 15.19 e 14.24, juntamente com PostgreSQL 19 Beta 3. O anúncio junta manutenção de linhas suportadas e uma pré-versão, mas os dois artefactos têm finalidades operacionais diferentes.

As cinco versões 18.6 a 14.24 são releases menores de linhas suportadas; 19 Beta 3 é uma pré-versão para teste. A política do projeto define linhas suportadas e calendário; sistemas fora de suporte exigem migração, não apenas mais uma atualização menor.

Replicação física exige compatibilidade da linha e o rollback pode precisar de restore ou failback planeado, não downgrade binário. Saltar notas porque uma atualização é 'minor' pode esconder mudanças que afetam planos, replicação ou extensões. Adiar porque não existe nova major mantém correções por aplicar; instalar a Beta em produção troca risco conhecido por comportamento ainda em avaliação.

Decisão, limites e condição de bloqueio

Atualize cada cluster para a menor mais recente da sua linha suportada após ler notas intermédias e testar extensões, replicação, backup e queries críticas. Use 19 Beta 3 apenas em laboratório para preparar compatibilidade; não o trate como substituto da linha estável.

Saltar notas porque uma atualização é 'minor' pode esconder mudanças que afetam planos, replicação ou extensões. Adiar porque não existe nova major mantém correções por aplicar; instalar a Beta em produção troca risco conhecido por comportamento ainda em avaliação.

Execução e prova de conclusão

A execução deve começar por inventariar versão, sistema operativo, extensão, topologia, réplica, backup, rpo, rto e dono por cluster. Depois, restaurar backup numa réplica, aplicar a menor-alvo e reproduzir queries, extensões, failover e jobs relevantes. O fecho exige promover por vaga com métricas antes/depois e manter 19 beta num ambiente separado, sem dados ou tráfego de produção.

O cluster fecha quando reporta a versão-alvo, backups e restauro foram provados, replicação está saudável, queries críticas mantêm tolerâncias e extensões são compatíveis; o laboratório Beta conserva um resultado separado.

• inventariar versão, sistema operativo, extensão, topologia, réplica, backup, RPO, RTO e dono por cluster.
• restaurar backup numa réplica, aplicar a menor-alvo e reproduzir queries, extensões, failover e jobs relevantes.
• promover por vaga com métricas antes/depois e manter 19 Beta num ambiente separado, sem dados ou tráfego de produção.
• O cluster fecha quando reporta a versão-alvo, backups e restauro foram provados, replicação está saudável, queries críticas mantêm tolerâncias e extensões são compatíveis; o laboratório Beta conserva um resultado separado.