PostgreSQL 19 deve sair em outubro com REPACK, autovacuum paralelo e JIT desligado

O PostgreSQL 19 está na reta final. O beta 4 saiu com a previsão de uma versão candidata no começo de outubro e de lançamento oficial, se os testes deixarem, ainda neste mês, segundo o anúncio do projeto. Quem administra banco tem pouco tempo para olhar o que muda, e algumas mudanças são de comportamento padrão, das que aparecem sem ninguém pedir.

O que chega de novo

As notas da versão destacam seis frentes:

• REPACK, um comando que recupera espaço em disco e reorganiza a tabela, juntando o que hoje se faz com VACUUM FULL e CLUSTER. Com a opção CONCURRENTLY, faz isso sem bloquear leituras e escritas na tabela;
• replicação lógica de sequências, e a replicação lógica pode ser ligada sem reiniciar o servidor quando o wal_level está em replica;
• autovacuum paralelo: ele pode usar processos paralelos para os índices de uma tabela, e um sistema de pontuação decide quais tabelas precisam de vacuum ou analyze primeiro;
• WAIT, um comando que espera a réplica aplicar as mudanças até um ponto escolhido, para ler na réplica o que acabou de ser gravado no primário;
• pg_plan_advice, uma extensão para estabilizar e controlar as decisões do planejador de consultas, com uma companheira, a pg_stash_advice, que aplica esses conselhos de forma automática;
• desempenho: ajuste automático da quantidade de processos de I/O, checagem de chave estrangeira mais rápida, COPY FROM acelerado com instruções SIMD para texto e CSV, e o NOTIFY acordando só os processos que escutam aquela notificação.

Os padrões que mudam

Três mudanças de configuração merecem atenção antes da atualização. O JIT passa a vir desligado: antes ele era ligado e acionado pelo custo estimado da consulta, mas essa estimativa se mostrou pouco confiável. Quem roda muitas consultas analíticas grandes vai precisar religá-lo:

SET jit = on;

A compressão padrão do TOAST, onde ficam os valores grandes das colunas, troca o pglz pelo lz4, mais eficiente. E o max_locks_per_transaction sobe de 64 para 128, mas a forma de reservar os locks mudou: na prática, quem tinha um valor configurado precisa dobrá-lo para ter a mesma capacidade de antes.

O que pede cuidado na migração

Como em toda versão principal, passar para a 19 exige pg_dumpall, pg_upgrade ou replicação lógica. E a lista de incompatibilidades tem itens de segurança:

O suporte a RADIUS foi removido, porque o PostgreSQL só o oferecia sobre UDP, o que as notas chamam de inseguro sem conserto. A autenticação por senha MD5, já marcada como obsoleta na 18, passa a gerar um aviso a cada login bem-sucedido, e um novo parâmetro avisa quando a senha está perto de expirar, por padrão com sete dias de antecedência. O standard_conforming_strings fica sempre ligado, e um dump feito por versões antigas do pg_dump com ele desligado não carrega direito na 19. Nomes de banco, de papel e de tablespace com quebra de linha passam a ser recusados.

Há também mudanças de comportamento menores: um json_array() que não encontra linhas devolve um array JSON vazio em vez de NULL, e o encoding MULE_INTERNAL foi removido.

O que ficou para depois

O beta 4 tirou da 19 recursos que estavam previstos: consultas de grafo em SQL (SQL/PGQ), a fusão e a divisão de partições com ALTER TABLE, o FOR PORTION OF para atualizar e apagar dados temporais e a ativação de checksums com o banco no ar. O projeto explica que preferiu a confiabilidade e o calendário previsível, e que esses recursos podem voltar numa versão futura.

Na prática, para a maioria das aplicações, a 19 é uma atualização de manutenção mais tranquila e mais rápida. O teste que vale fazer antes é rodar as consultas analíticas pesadas com o JIT desligado e conferir o tempo, e procurar senhas em MD5 que ainda estejam no caminho.

Fontes: PostgreSQL: notas da versão 19, PostgreSQL: anúncio do 19 Beta 4

Produzido com auxílio de IA e revisado pela redação.