Pg_kpart 1.0: extensão para evitar varreduras acidentais em tabelas particionadas do PostgreSQL

A pg_kpart 1.0 não é só mais uma extensão de segurança: ela opera no nível do planner do PostgreSQL, usando um planner_hook para inspecionar o plano de execução antes da execução, e rejeitar consultas que não conseguem podar partições. Isso é diferente de triggers ou policies, que atuam *após* a decisão de varredura. O mecanismo é preciso: se o predicado na chave de partição for inutilizável (ex.: função não imutável, comparação com coluna de outra tabela sem join condition adequada), a consulta é barrada com SQLSTATE '54000' (pg_kpart_violation), não com um erro genérico.

O projeto nasce de uma dor real em produção: tabelas particionadas com centenas de milhões de linhas em ambientes de analytics ou time-series, onde um único SELECT sem WHERE na chave pode travar o I/O por minutos. Gilles Darold, mantenedor e CTO da HexaCluster, tem histórico nisso, ele também criou o pgBadger (análise de logs) e o Ora2Pg (migração Oracle → PG). A pg_kpart é compatível com PostgreSQL 13+, mas exige compilação nativa no Linux, não roda em Windows nem macOS, nem em contêineres com glibc mínima sem suporte a pthreads robusto.

A versão 1.0 é a primeira estável, mas a CEVIU já havia coberto o protótipo em rascunho interno da HexaCluster em abril de 2026, então o que mudou foi a estabilidade técnica e a maturidade operacional. Antes, o hook era instável sob carga alta com paralelismo > 4; agora suporta até 16 workers. O modo de auditoria, que antes só logava em stderr, agora grava em tabela pg_kpart.audit_log com timestamp, usuário, query_hash e número de partições afetadas. Também foi adicionado suporte a blacklist por schema + tabela (ex.: public.events_*), algo ausente no beta.

Em pipelines de dados, particionamento mal usado é uma das maiores fontes de latência escondida. A pg_kpart fecha uma lacuna entre governança de acesso e governança de desempenho: ela não impede quem *pode* ler, mas garante *como* deve ler. Isso alinha diretamente com práticas de data engineering modernas, como o uso de partition pruning em ETLs incrementais ou em queries de BI com time-based filters. Não é um substituto para boas práticas de modelagem, mas um guardrail que evita que um único erro de código-fonte derrube SLA de todo o data warehouse.