Várias são as possibilidades que impedem uma conexão a uma instância postgresql. Mas uma das principais falhas cometidas por um DBA após a criação e disponibilização de uma instância do PostgreSQL, que impede a conexão de usuários ao serviço, é a configuração incorreta do arquivo postgresql.conf.

Melhor colocando, a falta de configuração neste aquivo das interfaces de rede que aceitarão os pedidos de conexão com a instância.

Normalmente isso acontece por uma desatenção do DBA no ajuste do parâmetro listen_addresses, dentro do principal arquivo de configurações do postgres, o postgresql.conf, que, por padrão, vem configurado para aceitar apenas conexões locais (listen_addresses = 'localhost’), impedindo todas as conexões remotas.

Para corrigir tal problema, o DBA deve permitir conexões por um IP específico, ou por qualquer endereço de IP, configurando o parâmetro da seguinte forma:

• listen_addresses = 'endereço 1, endereço 2 etc.’; ou
• listen_addresses = '*', sendo que o “*” significa que não haverá validação de um IP específico, o que permitiria, por exemplo, a substituição do IP da placa de rede local a qualquer momento, sem a necessidade de reconfiguração.

Tenha em mente que, após a alteração do parâmetro, é necessário que o serviço seja reiniciado.

Outro arquivo que também pode estar gerando bloqueio aos acessos é o arquivo de configuração pg_hba.conf.

Neste arquivo são definidas as regras de autenticação e acesso ao banco de dados, determinando quais usuários, hosts (origem do acesso) e métodos de autenticação são permitidos. Se as regras não forem ajustadas corretamente, mesmo que o serviço esteja rodando, o listen_addresses esteja configurado e tanto o database quanto o usuário existam, as conexões serão recusadas.

Diferentemente da primeira situação, a falha na configuração do pg_hba.conf exibe mensagens claras da razão da recusa, como por exemplo:

• “FATAL: no pg_hba.conf entry for host "xxx.xxx.xxx.xxx" ”;
• “FATAL: permission denied for database "banco_de_dados_X" ”; ou
• “FATAL: no pg_hba.conf entry for host "xxx.xxx.xxx.xxx", user "usuário", database "banco_de_dados_X" ”.

Dentre outras. Mas haverá uma indicação clara do ponto de falha que gerou o erro.

Já para a falha de configuração inicial, a mensagem de erro é um pouco enigmática, como “psql: error: connection to server at "192.168.56.33", port 5432 failed: Connection refused”, o que, convenhamos, dificulta a identificação, de imediato, da origem do problema.

Há, também, erros de fácil identificação, dada a mensagem emitida após a falha, como: “psql: error: connection to server at "192.168.56.33", port 5432 failed: FATAL: role "teste" is not permitted to log in”. Aqui, claramente somos alertados que o usuário “teste” não tem permissão para acessar o database indicado no comando psql de conexão; ou “psql: error: connection to server at "192.168.56.33", port 5432 failed: FATAL: database "abacate" does not exist”, onde é estampada a informação de que o banco indicado não existe na instância destino.

Outros erros que impedem a conexão são, por exemplo o fornecimento do conjunto IP:Porta incorreto, ou a existência de bloqueio da porta indicada no comando, seja pela existência de um firewall bloqueando a porta, ou mesmo uma porta diferente na configuração do arquivo postgresql.conf, daquela utilizada no comando psql.

Sugestão de passos a serem seguido para resolução do problema:

• Garanta que a configuração do parâmetro “listen_addresses”, dentro do arquivo postgresql.conf, permite acessos externos ao servidor.

• Verifique se o arquivo pg_hba.conf contém as regras necessárias para os serviços a serem prestados pela instância.

• Valide a permissão de tráfego na porta configurada para o serviço do postgresql (por padrão 5432).

• Certifique-se de que o usuário tem permissão de login e/ou acesso ao banco de dados.

   

Os passos acima resolvem a maioria dos problemas de conexão após a criação de uma instância do PostgreSQL, mas fique sempre atento aos logs. Esses arquivos trazem informações valiosas que poderão auxiliar na identificação da causa do erro.

Ah! Após alterações, reinicie o serviço PostgreSQL para aplicar as mudanças.

Até o próximo artigo!