O PostgreSQL 19 está na reta final do seu ciclo de desenvolvimento. Depois de uma sequência de versões beta e da primeira release candidate, a comunidade disponibiliza a RC2, incorporando novas correções antes do lançamento oficial.
No artigo PostgreSQL 19 RC1: o que mudou desde o Beta 4 e o que acompanhar antes do lançamento, abordamos a evolução da versão, as mudanças acumuladas durante o desenvolvimento e os pontos que mereciam atenção na etapa de estabilização.
Agora, com a chegada da RC2, o foco muda. Mais do que acompanhar a implementação de funcionalidades, é o momento de observar as correções que afetam o comportamento do PostgreSQL, especialmente em aspectos como integridade dos dados, execução de consultas, performance e disponibilidade.
O anúncio da RC2 reúne oito grupos de correções específicas desde a RC1, além das correções aplicáveis ao PostgreSQL 19 incluídas nas atualizações de novembro das versões suportadas.
A release estável do PostgreSQL 19 está prevista para 19 de novembro de 2026, desde que não sejam identificados problemas que exijam novos ajustes ou outra release candidate.
Neste artigo, vamos analisar o que mudou desde a RC1, por que determinadas correções merecem atenção e quais validações devem fazer parte dos testes antes da adoção da nova versão.
O que mudou entre o PostgreSQL 19 RC1 e a RC2?
A segunda release candidate concentra correções identificadas durante os testes da RC1. Embora não representem necessariamente mudanças visíveis para todos os usuários, algumas delas afetam diretamente a confiabilidade de operações SQL e o comportamento do banco em situações específicas.
As principais alterações podem ser organizadas em quatro frentes:
| Área | Correções na RC2 |
| Integridade e resultados de consultas | Correções em GROUPING SETS e reversão de uma alteração envolvendo JSON_ARRAY() e JSON_OBJECT(). |
| Execução e performance | Ajustes em eager aggregation e correções de regressões em operações baseadas em hash. |
| Disponibilidade e comunicação | Correções na promoção de servidores standby e no processamento de notificações LISTEN/NOTIFY. |
| Compatibilidade e comportamento SQL | Correções em verificações de chaves estrangeiras e funções de janela com IGNORE NULLS. |
Essas mudanças mostram por que a fase de release candidate é importante. Mesmo quando o conjunto de funcionalidades já está próximo do definitivo, os testes ainda podem revelar problemas relacionados à semântica das consultas, ao uso de recursos e à interação entre diferentes componentes do PostgreSQL.
Reversão envolvendo JSON: um cuidado com a integridade dos dados
Uma das alterações mais relevantes da RC2 é a reversão de um comportamento relacionado às funções JSON_ARRAY() e JSON_OBJECT().
Durante o desenvolvimento do PostgreSQL 19, uma mudança passou a permitir o uso de determinadas expressões dessas funções, envolvendo arrays, tipos compostos e tipos range, em estruturas como:
- Índices de expressão;
- Colunas geradas;
- Chaves de particionamento.
O problema é que essas expressões poderiam produzir estruturas desatualizadas, comprometendo a consistência entre os valores armazenados ou indexados e os dados de origem.
Por isso, a RC2 reverte essa permissão nos casos afetados.
Qual é a implicação prática?
Ambientes utilizados para testar versões anteriores do PostgreSQL 19 podem conter objetos criados com esse comportamento.
Caso existam, será necessário removê-los ou redefini-los antes da atualização. Do contrário, processos de migração utilizando pg_upgrade ou pg_dump/pg_restore poderão falhar ao tentar recriar essas estruturas.
A correção é particularmente importante porque demonstra que nem toda alteração introduzida durante o desenvolvimento de uma versão será necessariamente mantida até o lançamento.
Para quem acompanha as versões beta e RC, isso reforça a necessidade de revisar mudanças de compatibilidade, especialmente quando envolvem objetos persistentes do banco.
GROUPING SETS: correção de resultados incorretos
Outra correção importante envolve consultas que utilizam GROUPING SETS.
Esse recurso permite calcular diferentes agrupamentos em uma mesma consulta, sendo bastante utilizado em operações analíticas e na geração de relatórios.
O problema identificado poderia fazer com que uma coluna não pertencente ao agrupamento corrente apresentasse um valor em vez de NULL.
Considere uma consulta como:
SELECT regiao, produto, SUM(valor)
FROM vendas
GROUP BY GROUPING SETS (
(regiao),
(produto)
);
Nesse exemplo, cada conjunto de agrupamento produz resultados com diferentes níveis de agregação.
Nas linhas agrupadas apenas por região, a coluna produto deve apresentar NULL, já que ela não faz parte daquele agrupamento. O mesmo princípio se aplica à coluna regiao nas linhas agrupadas apenas por produto.
O erro corrigido na RC2 poderia violar essa expectativa.
Por que isso importa?
Diferentemente de uma regressão de performance, um problema de resultado incorreto pode passar despercebido caso a aplicação continue executando normalmente.
Isso é especialmente relevante em sistemas analíticos, relatórios gerenciais e processos que utilizam resultados agregados para alimentar outras operações.
A correção reforça a importância de incluir testes de resultado, e não apenas de tempo de execução, na avaliação de uma nova versão.
Eager aggregation: preservar a semântica das consultas
O PostgreSQL 19 introduz melhorias relacionadas à antecipação de operações de agregação, conhecidas como eager aggregation.
A proposta é permitir que determinadas agregações sejam realizadas mais cedo no plano de execução, quando isso for vantajoso e semanticamente correto.
Entretanto, durante os testes da RC1, foi identificado um problema envolvendo funções voláteis utilizadas em condições de junção.
Em determinadas situações, essas funções poderiam ser executadas uma vez por grupo, quando o comportamento esperado era sua execução uma vez por linha.
A diferença é importante porque funções classificadas como VOLATILE podem produzir resultados diferentes a cada chamada ou apresentar efeitos colaterais.
Ao alterar a quantidade de execuções de uma função, o planejador pode modificar não apenas o custo da consulta, mas também seu comportamento.
A RC2 corrige esse cenário.
O que observar nos testes?
Consultas complexas que combinam junções, agregações e funções voláteis merecem atenção especial.
Além de comparar os planos de execução com EXPLAIN (ANALYZE, BUFFERS), é importante verificar se os resultados permanecem equivalentes aos obtidos na versão atualmente utilizada.
A otimização de uma consulta só é válida quando preserva sua semântica. Esse é um dos princípios fundamentais que orientam o desenvolvimento do planejador de consultas do PostgreSQL.
Operações baseadas em hash: correções de regressões de performance
A RC2 também corrige regressões de performance relacionadas à execução de consultas que utilizam estruturas hash.
Um dos problemas identificados envolvia o dimensionamento dessas estruturas a partir das estimativas do planejador.
Em determinadas condições, tabelas hash poderiam ser dimensionadas muito além do limite definido por work_mem, dependendo da estimativa de quantidade de linhas.
É importante lembrar que work_mem não representa um limite global de memória para uma consulta. Ele é utilizado como referência para operações individuais de execução, e uma mesma consulta pode realizar múltiplas operações que consomem memória.
Além disso, operações hash podem utilizar um limite calculado a partir de work_mem e hash_mem_multiplier.
O problema corrigido na RC2 está relacionado ao dimensionamento inadequado dessas estruturas, e não a uma mudança geral na finalidade de work_mem.
Qual é o impacto para os DBAs?
Consultas que utilizam hash joins ou hash aggregation devem fazer parte dos testes de regressão de performance, principalmente em ambientes com grandes volumes de dados.
A avaliação pode considerar:
- Diferenças nos planos de execução;
- Consumo de memória durante as consultas;
- Ocorrência de operações em disco;
- Tempo de execução;
- Comportamento sob concorrência.
Esses testes ajudam a identificar se as mudanças no planejador e no executor produzem resultados adequados para as características reais da carga de trabalho.
Correções relacionadas à disponibilidade e ao comportamento operacional
Além das alterações em consultas SQL, a RC2 inclui correções em mecanismos importantes para a operação do PostgreSQL.
Promoção de standby: correção de espera indefinida
Um dos problemas corrigidos poderia fazer com que a promoção de um servidor standby aguardasse indefinidamente.
O cenário envolvia uma sessão bloqueada ao tentar enviar dados para um cliente que havia parado de consumir a resposta.
Durante a promoção, essa condição poderia impedir a conclusão do processo.
Em arquiteturas de alta disponibilidade, a promoção de um standby é uma etapa crítica para restabelecer a capacidade de escrita após a indisponibilidade do servidor primário.
Embora o problema estivesse associado a uma condição específica, seu impacto potencial merece atenção: um processo de promoção que não termina pode comprometer o tempo de recuperação esperado.
A correção não elimina a necessidade de testar procedimentos de failover.
Para ambientes que estão avaliando o PostgreSQL 19, é recomendável validar a promoção de standby em cenários controlados, incluindo situações com sessões ativas e clientes que apresentam comportamento anormal.
LISTEN/NOTIFY: correção no processamento de notificações
O mecanismo LISTEN/NOTIFY permite que sessões PostgreSQL enviem e recebam notificações assíncronas.
Ele pode ser utilizado em aplicações que precisam sinalizar eventos entre diferentes conexões, sem depender exclusivamente de consultas periódicas.
Na RC1, foi identificado um problema em que a fila de notificações poderia ficar travada caso uma sessão fosse interrompida durante a leitura das notificações.
A RC2 corrige esse comportamento.
Para aplicações que dependem desse mecanismo, os testes devem considerar não apenas o envio e o recebimento de notificações em condições normais, mas também interrupções de conexão e encerramentos inesperados de sessões.
É importante destacar que LISTEN/NOTIFY não substitui um sistema de mensageria persistente. A correção trata de um problema específico no processamento interno das notificações, sem alterar as características fundamentais desse mecanismo.
Outras correções de compatibilidade e comportamento SQL
Duas alterações adicionais merecem registro, especialmente para aplicações que utilizam funcionalidades SQL mais específicas.
Funções de janela com IGNORE NULLS
A RC2 corrige um problema que poderia provocar um loop infinito nas funções first_value() e nth_value() ao utilizar IGNORE NULLS em combinação com determinadas opções EXCLUDE da definição da janela.
O comportamento afetava combinações específicas dessas funcionalidades.
Para aplicações que utilizam funções de janela em consultas analíticas, é recomendável incluir esses cenários nos testes de compatibilidade.
Verificações de chaves estrangeiras
Também foi corrigido um problema em verificações de integridade referencial quando os tipos das colunas envolvidas exigiam uma conversão para permitir a comparação.
Nessas situações, a verificação de uma chave estrangeira poderia falhar com erro, mesmo quando a comparação deveria ser possível.
A correção é relevante para esquemas que utilizam tipos diferentes, mas compatíveis mediante conversão, nas colunas de relacionamentos.
Esses casos reforçam a importância de testar operações de escrita e validação de restrições, além das consultas de leitura.
O que validar antes de adotar o PostgreSQL 19?
A proximidade do lançamento oficial não significa que uma atualização de versão principal deva ser realizada sem planejamento.
A RC2 representa uma oportunidade para revisar os testes já executados e direcionar novas validações aos componentes que receberam correções.
Para ambientes que estão considerando o PostgreSQL 19, recomendamos organizar essa avaliação em cinco frentes.
Validar a equivalência dos resultados
Os testes devem verificar se consultas críticas continuam produzindo resultados corretos.
Isso inclui consultas com agregações complexas, GROUPING SETS, funções de janela e condições de junção que utilizam funções voláteis.
Comparar apenas o tempo de execução não é suficiente. É necessário garantir que as otimizações não alterem o comportamento esperado da aplicação.
Avaliar regressões de performance
A comparação de desempenho deve utilizar cargas de trabalho representativas, com volumes de dados, estatísticas e padrões de concorrência próximos aos encontrados em produção.
Ferramentas e recursos como EXPLAIN (ANALYZE, BUFFERS) e pg_stat_statements podem apoiar essa avaliação.
O objetivo não é apenas identificar consultas mais lentas, mas compreender alterações de planos, consumo de recursos e possíveis mudanças de comportamento sob carga.
Revisar os procedimentos de alta disponibilidade
Ambientes com replicação física e mecanismos automatizados de failover devem validar seus procedimentos de promoção, recuperação e reconexão das aplicações.
A correção incluída na RC2 é um motivo adicional para verificar esses cenários, mas os testes precisam considerar toda a arquitetura de alta disponibilidade, incluindo ferramentas externas de orquestração, quando utilizadas.
Revisar os objetos e as extensões utilizados
A atualização para uma nova versão principal exige atenção à compatibilidade de extensões, índices, funções e demais objetos do banco.
No caso do PostgreSQL 19, há uma orientação específica para ambientes que utilizam pg_upgrade: índices relacionados a full-text search, pg_trgm e fuzzystrmatch podem exigir reindexação após a migração.
A necessidade depende dos objetos e das definições utilizadas. Portanto, é importante consultar a seção Migration to Version 19, nas notas oficiais da versão, para identificar quais índices são afetados.
Também é necessário revisar eventuais objetos criados durante os testes das versões preliminares com as expressões JSON cuja utilização foi revertida na RC2.
Planejar a estratégia de atualização
A migração de uma versão principal anterior para o PostgreSQL 19 exige uma estratégia de major upgrade.
Entre as alternativas estão pg_upgrade e pg_dump/pg_restore, além de estratégias baseadas em replicação lógica quando compatíveis com os requisitos e as características do ambiente.
A escolha deve considerar volume de dados, janela de indisponibilidade, compatibilidade das aplicações, dependências e possibilidades de retorno à versão anterior.
É importante diferenciar esse processo das atualizações menores das versões já suportadas, que normalmente não exigem pg_upgrade.
O que esperar até o lançamento oficial?
De acordo com o cronograma divulgado pela comunidade, o lançamento geral do PostgreSQL 19 está previsto para 19 de novembro de 2026.
A RC2 deve ser muito próxima da versão final, mas ainda existe a possibilidade de novas correções caso sejam identificados problemas relevantes.
Isso significa que o conjunto de funcionalidades está em fase avançada de estabilização, mas a versão ainda não deve ser tratada como um lançamento definitivo.
Outro ponto importante é que a RC2 também incorpora as correções aplicáveis ao PostgreSQL 19 presentes no ciclo de atualizações de novembro.
Esse ciclo inclui mais de 140 correções distribuídas entre as versões suportadas, envolvendo questões de integridade, índices, backups, replicação e execução de consultas.
Entre os acontecimentos desse período também está o encerramento do suporte ao PostgreSQL 14, que recebe sua última atualização.
Para os profissionais responsáveis pela manutenção dos ambientes, são duas frentes distintas de planejamento: acompanhar a estabilização do PostgreSQL 19 e manter as versões atualmente utilizadas dentro de um ciclo de suporte adequado.
O que a RC2 representa para quem administra PostgreSQL?
A RC2 mostra que o processo de estabilização do PostgreSQL 19 continua avançando, com correções que vão além de ajustes pontuais de performance.
A reversão envolvendo expressões JSON, os problemas de resultados incorretos em consultas e as correções relacionadas à promoção de standby demonstram a importância dos testes realizados pela comunidade antes de uma nova versão chegar à disponibilidade geral.
Para DBAs, DSEs e profissionais responsáveis pela arquitetura e operação de ambientes PostgreSQL, esse período é uma oportunidade para antecipar avaliações técnicas, identificar incompatibilidades e construir um plano de atualização baseado em evidências.
A proximidade do lançamento não elimina os riscos de uma migração. Ela permite que esses riscos sejam estudados com mais informações sobre o comportamento da nova versão.
O PostgreSQL 19 está cada vez mais próximo. A questão agora não é apenas conhecer suas funcionalidades, mas compreender como elas se comportam nas cargas de trabalho que precisam sustentar.
Acompanhe as notas oficiais do PostgreSQL 19 e continue acompanhando o blog da Timbira para análises técnicas sobre as próximas etapas da versão.