O PostgreSQL 14 recebeu em 12 de novembro a atualização 14.25, a última prevista para a série. O PostgreSQL Global Development Group anunciou 52 correções de segurança e mais de 140 correções de bugs no conjunto de versões atualizadas. Para quem mantém bancos em produção, a decisão imediata é aplicar as correções disponíveis e planejar a saída da série 14, que chegou ao fim do suporte comunitário.
O pacote também trouxe PostgreSQL 15.20, 16.16, 17.12 e 18.7. A versão 19 recebeu um segundo candidato a lançamento, ainda em teste. As 52 vulnerabilidades são o total informado para o conjunto do lançamento. As falhas e as condições de exploração variam por versão, extensão instalada e permissões dos usuários.
O que muda com o fim do suporte ao PostgreSQL 14
A política de versões do PostgreSQL prevê cerca de cinco anos de correções para cada série principal. O servidor continua funcionando depois desse prazo. A partir do fim do ciclo, a série deixa de receber do projeto as correções que chegarem às versões mantidas, inclusive as de segurança. Quem usa um serviço gerenciado deve conferir a janela e as condições do fornecedor, que pode ter um calendário próprio.
A atualização de 14.x para 14.25 é uma revisão da mesma série. As notas da versão 14.25 indicam que bancos já na série 14 dispensam exportação e restauração para esse passo. A passagem para o PostgreSQL 15 ou superior é uma atualização principal e requer um procedimento de migração. É possível pular séries intermediárias, desde que as mudanças de compatibilidade das versões atravessadas sejam levadas em conta.
Quais correções merecem atenção na versão 14.25
Uma das correções envolve permissões em consultas que usam INSERT ... ON CONFLICT sobre visões atualizáveis. Dependendo da configuração, a operação podia alcançar linhas fora da condição da visão. Para aplicações que usam visões para restringir quais registros cada usuário enxerga ou altera, vale revisar os testes de autorização dessas operações depois da atualização.
Outras falhas afetam ambientes com componentes específicos, como dblink ou procedimentos escritos em PL/Perl. Inventariar extensões e funções em cada banco ajuda a avaliar o risco real. Um inventário de versões sozinho informa quais instâncias precisam de atenção. Para entender o alcance de cada falha, é preciso cruzar a versão com as extensões e os privilégios em uso.
Como preparar a migração da série 14
Comece pelas instâncias ativas, incluindo réplicas e ambientes de recuperação. Para cada uma, identifique a versão em execução, as extensões, o tamanho do banco e a janela disponível para indisponibilidade. Ao escolher a série de destino, confira a data de fim do suporte e a disponibilidade das extensões e ferramentas de backup para essa versão.
Em uma instalação administrada pela própria equipe, a documentação do pg_upgrade explica como rodar a verificação pg_upgrade --check antes da migração para a série 18. O comando verifica a compatibilidade da instalação e indica ajustes necessários. Um ensaio com dados restaurados também permite medir a janela e confirmar a abertura da aplicação, as permissões e a recuperação do banco. Em serviços gerenciados, confira quais desses passos o provedor executa e como o retorno à versão anterior é tratado.
A troca de versão também pode mudar planos de execução. Guardar o tempo e o plano das consultas mais importantes antes da migração dá uma referência para investigar regressões depois da troca. A conferência pode começar pelas consultas de maior volume e pelas rotinas que consomem mais tempo. O guia de EXPLAIN do Ponto Nulo mostra como ler esses planos.
