PostgreSQL 19 e o REPACK (CONCURRENTLY): Análise dos Custos Operacionais

O REPACK (CONCURRENTLY) no PostgreSQL 19 revoluciona a reescrita de tabelas. Ele centraliza as funcionalidades de VACUUM FULL e CLUSTER, permitindo a operação online. A ferramenta usa o mecanismo de decodificação lógica, o mesmo da replicação. Ela cria um slot temporário de replicação para tirar um snapshot. Todas as mudanças na tabela durante a cópia são coletadas do WAL por um worker em segundo plano. Depois de copiar as linhas visíveis do snapshot para um novo arquivo e reconstruir os índices, o REPACK aplica essas mudanças acumuladas.

A fase final exige um bloqueio ACCESS EXCLUSIVE breve para aplicar as últimas alterações e trocar os arquivos. Esta é a única interrupção para escrita. É crucial notar que o REPACK (CONCURRENTLY) não é MVCC-safe. Transações REPEATABLE READ longas podem ver uma tabela vazia se o REPACK terminar antes de elas lerem. Outro ponto crítico é o limite de cerca de 105 milhões de atualizações ou exclusões durante a execução. Ultrapassar isso causa falha e pode levar a um OOM kill, derrubando o banco de dados.

A grande novidade é que o que antes dependia de extensões externas como pg_repack ou pg_squeeze agora está integrado ao PostgreSQL. A notícia atual detalha que o REPACK (CONCURRENTLY) é uma funcionalidade nativa do PostgreSQL 19. Isso significa menor dependência de componentes externos e maior facilidade de uso, especialmente em serviços gerenciados. A cobertura anterior do CEVIU sobre o PostgreSQL 19, como a de 20 de agosto de 2026, já apontava para um foco em otimizações e melhorias de desempenho. Esta nova funcionalidade é uma entrega concreta dessas promessas de performance, oferecendo uma forma mais otimizada e eficiente de lidar com o inchaço de tabelas.

Para desenvolvedores e DBAs, a chegada do REPACK (CONCURRENTLY) no PostgreSQL 19 é um passo importante na gestão de bancos de dados. A ferramenta simplifica a manutenção de tabelas online, eliminando a necessidade de extensões e seus pré-requisitos, como o shared_preload_libraries. Isso a torna acessível em ambientes onde extensões são restritas. Contudo, a análise dos custos operacionais mostra que esta otimização não vem sem contrapartidas. Impactos no VACUUM global, um breve bloqueio de escritas e o limite de 105 milhões de mudanças exigem um planejamento cuidadoso para garantir que a funcionalidade seja utilizada de forma eficiente e segura, sem comprometer a estabilidade do sistema.