Arquitetura do Postgres

O PostgreSQL é um servidor multi-processo: um postmaster supervisor cria processos backend para cada conexão de cliente, enquanto workers de background mantêm a durabilidade e a higiene do cache. Entender essa divisão explica limites de conexão, dimensionamento de memória e por que reinícios (restarts) vs. recarregamentos (reloads) são diferentes.

Receita

-- Veja os backends ativos e o que eles estão executando
SELECT pid, usename, application_name, state, wait_event_type, query
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY state, pid;

# Recarrega a configuração sem descartar conexões (muitos GUCs)
pg_ctl reload -D /var/lib/postgresql/18/main
 
# Reinício completo recicla o postmaster e todos os seus filhos
pg_ctl restart -D /var/lib/postgresql/18/main

Quando usar isso: Você precisa raciocinar sobre conexões, memória, checkpoints ou por que uma configuração requer um reinício.

Exemplo de Trabalho

-- Dica da taxa de geração de WAL (bytes por ciclo de checkpoint)
SELECT checkpoints_timed, checkpoints_req,
       wal_bytes, buffers_checkpoint
FROM pg_stat_bgwriter;
 
-- Taxa de acerto do shared buffer (nível do banco de dados)
SELECT sum(blks_hit)::float / nullif(sum(blks_hit) + sum(blks_read), 0) AS cache_hit_ratio
FROM pg_stat_database;

O que isso demonstra:

• pg_stat_activity separa backends de clientes de workers de background.
• pg_stat_bgwriter expõe o volume de checkpoint e WAL.
• A taxa de acerto do buffer aproxima a frequência com que as leituras vêm de shared_buffers vs. disco.
• Recarregar vs. reiniciar é uma distinção operacional ligada ao ciclo de vida do postmaster.

Mergulho Profundo

Modelo de Processos

• Postmaster escuta na porta e cria um novo backend para cada conexão TCP (a menos que haja pooling).
• Background writer é o responsável por descarregar páginas sujas (dirty pages); checkpointer finaliza segmentos de WAL e avança os pontos de redo.
• WAL writer agrupa os fsyncs do buffer de WAL; autovacuum launcher agenda workers de vacuum/analyze para tabelas.
• Workers de Stats collector e logical replication aparecem como tipos adicionais de background.

Layout de Memória

• shared_buffers contém páginas de dados em cache compartilhadas por todos os backends.
• Cada backend tem work_mem (por nó de ordenação/hash) e maintenance_work_mem (para VACUUM, CREATE INDEX).
• effective_cache_size é uma dica para o planejador sobre o cache de páginas do SO, não RAM alocada.

Caminho de Durabilidade

1. O backend modifica a página do shared buffer e insere um registro de WAL.
2. O WAL é descarregado para o disco (o commit depende de synchronous_commit).
3. O checkpoint escreve as páginas sujas; a recuperação de falhas refaz o WAL a partir do último checkpoint.

Armadilhas

• Um backend por conexão - Sem PgBouncer, 500 threads de aplicativo podem significar 500 processos Postgres. Correção: Use pooling na aplicação ou PgBouncer; ajuste max_connections corretamente.
• work_mem se multiplica - Dez ordenações paralelas em uma única consulta podem usar 10x work_mem. Correção: Limite work_mem; observe o EXPLAIN para nós de Ordenação/Hash.
• Reload não aplica tudo - Mudanças em shared_buffers exigem reinício. Correção: Verifique o pg_settings.context antes de assumir que o reload funciona.
• Idle na transação por muito tempo - Transações abertas bloqueiam o vacuum e retêm versões de linha. Correção: Defina idle_in_transaction_session_timeout.
• Autovacuum não é opcional - Atualizações/exclusões deixam tuplas mortas até que o vacuum seja executado. Correção: Monitore pg_stat_user_tables.n_dead_tup.

Alternativas

FAQs

Relacionados

• Noções Básicas de PostgreSQL - tour por cluster, schema e tabela
• Noções Básicas de Instalação - pacotes e layout do diretório de dados
• Noções Básicas de Transações - MVCC e WAL da visão da sessão
• Noções Básicas de Pooling de Conexão - reduzindo o número de backends

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.