Gerenciando o PostgreSQL do terminal: o que funciona e o que não funciona
A maioria das pessoas confunde o cliente de linha de comando com o próprio serviço. Quando você digita psql, está abrindo uma interface interativa para conversar com o servidor. O serviço em si é algo completamente diferente: o processo postgres que roda como daemon, aceita conexões, gerencia memória e grava no disco. Entender essa separação evita metade dos problemas que aparecem no dia a dia.
o comando do sistema gerenciador de banco de dados postgresql
O que a maioria procura quando fala em "comando" depende inteiramente do que precisa fazer naquele momento. Para administrar o serviço, o caminho mais direto é usar o sistema de init da sua distribuição. No Debian e Ubuntu: sudo systemctl status postgresql
sudo systemctl restart postgresql sudo systemctl enable postgresql
No RHEL, CentOS ou Fedora, a sintaxe é praticamente a mesma, mas o usuário padrão do serviço chama-se postgres e não postgres com privilégios de sudo para tudo. Você entra assim: sudo -i -u postgres
👉 Clique no botão abaixo para saber mais sobre o assunto!
A partir daí, o prompt muda e você já está dentro do contexto correto. O erro mais comum que vejo em fóruns é alguém tentar conectar como root e receber "FATAL: role "root" does not exist". O PostgreSQL não se importa com quem você é no sistema operacional se não mapear isso para um role. Dentro do psql, os comandos mais úteis no dia a dia são aqueles que não exigem que você decore sintaxe SQL completa. O comando \du lista roles, \l mostra bancos, \dt lista tabelas no schema atual, \conninfo exibe informações da conexão corrente. O \xliga (ou \x) ativa a exibição expandida, que transforma linhas em colunas e evita que consultas com muitos campos fiquem ilegíveis no terminal.
Cheguei num caso específico onde precisei restaurar uma base de produção de 40 GB e o pg_restore travava aleatoriamente sem mensagem de erro. O problema era que o servidor tinha work_mem configurado para 4 MB no postgresql.conf e o restore estava usando muito mais que isso em operações de sort. A solução foi rodar o restore com uma configuração temporária: pg_restore --set work_mem=256MB -d database arquivo.dump. Isso cortou o tempo de restauração de quase duas horas para cerca de quinze minutos, porque o servidor parou de fazer spill para disco. Outra coisa que ninguém sempre menciona: o comando createdb é basicamente um wrapper para CREATE DATABASE, mas com um comportamento diferente em relação à template. Por padrão, ele clona a template1, o que significa que qualquer extensão ou objeto que você adicionou manualmente à template1 vai aparecer em todos os bancos criados depois. Se você quer um banco limpo, use createdb -T template0 nome_do_banco. A template0 é realmente vazia. A template1 não é.
Para monitoramento rápido sem instalar nada, o comando pg_stat_activity dentro do psql é insubstituível. Uma consulta simples como SELECT pid, usename, datname, state, query_start, now() - query_start AS duration, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY query_start; mostra todas as queries ativas com seu tempo de execução. O campo state pode ser active, idle, idle in transaction, or idle in transaction (aborted). O último é perigoso porque significa que uma transação ficou aberta e o lock não foi liberado. Backup inteligente com pg_dump exige atenção ao formato. O formato personalizado (-Fc) é o recomendado para a maioria dos casos porque permite restauração seletiva, compressão nativa e paralelismo. O formato tar (-Ft) é compatível mas não suporta restauração paralela. O formato textual (-Fp) é legível por humanos mas não compressível e lento para bases grandes. Para uma base de 20 GB, um dump personalizado com 4 workers leva cerca de 8 minutos. O mesmo dump no formato textual leva aproximadamente 45 minutos.
Um problema recorrente que eu enfrento: ao criar um banco com codificação UTF-8 e colação pt_BR.UTF-8, scripts SQL que foram escritos com acentos em editores que salvam em ISO-8859-1 funcionam perfeitamente na criação mas falham silenciosamente nas inserções porque a codificação da conexão não corresponde. A solução é sempre especificar SET client_encoding TO 'UTF8'; ou garantir que o ambiente do cliente tenha a variável LANG configurada corretamente antes de conectar. O psql por padrão herda a codificação do locale do sistema operacional, então se o seu terminal estiver em en_US.UTF-8 e o banco em pt_BR.UTF-8, a conversão é automática. Mas se você rodar o psql via cron sem um locale definido, a codificação padrão volta a ser SQL_ASCII e tudo que não for ASCII puro vira lixo. Para indexação, o que a maioria esquece é que o PostgreSQL não reindexa automaticamente quando a porcentagem de tuplas mortas ultrapassa um limiar. Você pode verificar com SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;. Se n_dead_tup estiver acima de 10% do total de linhas, um VACUUM FULL pode ser necessário, mas cuidado: esse comando trava a tabela inteira. Para produção, prefira o VACUUM normal ou o pg_repack, que reindexa sem bloqueio significativo.
O comando ALTER SYSTEM é útil mas perigoso se usado sem compreensão. Ele grava diretamente no postgresql.auto.conf, que tem prioridade sobre o postgresql.conf principal. Isso significa que qualquer par chave-valor definido ali sobrescreve o arquivo de configuração principal. Se você modificar work_mem com ALTER SYSTEM e depois esquecer, vai passar horas procurando no postgresql.conf sem encontrar a linha que está sendo sobrescrita. Para saber o que está ativo, rode SHOW ALL; e verifique a coluna source de cada parâmetro. Por fim, uma limitação que o PostgreSQL tem e que precisa ser dita claramente: o controle de concorrência baseado em MVCC é poderoso, mas para workloads de escrita extremamente alta em tabelas, ele sofre com bloat de tuplas mortas e degradação de performance em funções de agregação. Se o seu cenário envolve mais de 10 mil inserts por segundo na mesma tabela sem particionamento, considere particionar por faixa ou lista antes de começar. Particionar depois que os dados estão lá é muito mais doloroso do que planejar desde o início.
