Antes de ser possível acessar o banco de dados, o servidor de
banco de dados deve ser ativado.
O programa servidor de banco de dados se chama
postgres.
Se estiver sendo usada uma versão pré-empacotada do PostgreSQL, esta versão quase certamente inclui provisões para executar o servidor como um processo em segundo plano, conforme as convenções do sistema operacional de destino. Usar a infraestrutura do pacote para iniciar o servidor é muito menos trabalhoso do que descobrir como fazer isto sozinho. Consulte a documentação do pacote para obter detalhes.
A maneira mais simples para iniciar o servidor manualmente é apenas
executar o postgres diretamente, especificando
o local do diretório de dados com a opção -D.
Por exemplo,
$ postgres -D /usr/local/pgsql/data
deixa o servidor processando em primeiro plano.
Este comando deve ser executado estando conectado à conta de usuário
do PostgreSQL.
Sem a opção -D, o servidor tenta usar o diretório
de dados indicado pela variável de ambiente PGDATA.
Se esta variável também não estiver presente, então o comando falha.
Normalmente, é melhor iniciar o postgres em segundo
plano.
Para fazer isto, pode ser usada a sintaxe usual do interpretador de
comandos do Unix:
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &
É importante armazenar as saídas stdout e stderr do servidor em algum lugar, como mostrado acima. Armazenar as saídas é bom para fins de auditoria e diagnóstico de problemas. (Veja Manutenção de arquivo de registro para obter uma discussão mais completa sobre o manuseio de arquivos de registro.)
O programa postgres também aceita várias outras
opções de linha de comando.
Para obter mais informações, veja a página de referência do
postgres, e Configuração do servidor.
Esta sintaxe de interpretador de comandos pode se tornar cansativa rapidamente. Por isto, é fornecido o programa invólucro pg_ctl para simplificar algumas tarefas. Por exemplo,
pg_ctl start -l logfile
inicia o servidor em segundo plano, colocando a saída no arquivo de
registro de escrita antecipada indicado.
A opção -D tem o mesmo significado aqui que para
o postgres.
O pg_ctl também consegue parar o servidor.
Normalmente, se deseja iniciar o servidor de banco de dados quando o
computador é ligado.
Os scripts de início automático são específicos do sistema operacional.
Existem alguns scripts de exemplo distribuídos com o
PostgreSQL no diretório
contrib/start-scripts.
A instalação do script exige privilégios de usuário
root.
Sistemas operacionais diferentes têm convenções diferentes para
iniciar processos no momento de sua ativação.
Muitos sistemas usam o arquivo /etc/rc.local,
ou /etc/rc.d/rc.local.
Outros usam o diretório init.d ou
rc.d.
Seja da maneira que for, o servidor deve ser executado pela conta de
usuário do PostgreSQL,
e não pelo usuário root,
ou por qualquer outro usuário.
Portanto, o comando provavelmente deve trer a forma
su postgres -c '...'. Por exemplo:
su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'
A seguir estão algumas sugestões adicionais por sistema operacional. (Em cada caso, certifique-se de usar o diretório de instalação e o nome de usuário corretos, onde estão mostrados valores genéricos.)
Para o FreeBSD,
veja o arquivo
contrib/start-scripts/freebsd na distribuição
do código-fonte do PostgreSQL.
Para o OpenBSD, deve-se adicionar as
seguintes linhas ao arquivo /etc/rc.local:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s \
-l /var/postgresql/log \
-D /usr/local/pgsql/data'
echo -n ' postgresql'
fi
Nos sistemas Linux deve-se adicionar
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
ao arquivo /etc/rc.d/rc.local,
ou ao arquivo /etc/rc.local,
ou visto o arquivo
contrib/start-scripts/linux na distribuição
do código-fonte do PostgreSQL.
Quando é usado o
systemd,
pode-se adicionar o seguinte arquivo de unidade de serviço (por exemplo,
em /etc/systemd/system/postgresql.service):
[Unit] Description=PostgreSQL database server Documentation=man:postgres(1) After=network-online.target Wants=network-online.target [Service] Type=notify User=postgres ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data ExecReload=/bin/kill -HUP $MAINPID KillMode=mixed KillSignal=SIGINT TimeoutSec=infinity [Install] WantedBy=multi-user.target
O uso de Type=notify requer que o binário do
servidor tenha sido construído com
configure --with-systemd.
Deve ser considerada cuidadosamente a configuração do tempo limite
(timeout).
O systemd tem um tempo limite padrão
de 90 segundos (quando da escrita dessa documentação), matando
o processo que não sinalizar estar pronto dentro desse tempo limite.
Mas um servidor PostgreSQL tendo
que executar a recuperação de falhas na ativação, pode levar
muito tempo para ficar pronto.
O valor sugerido infinity desativa a lógica de
tempo limite.
No NetBSD, deve-se usar os scripts de ativação do FreeBSD ou do Linux, dependendo da preferência.
No Solaris, deve-se criar
um arquivo chamado /etc/init.d/postgresql,
contendo a seguinte linha:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start \
-l logfile \
-D /usr/local/pgsql/data"
Em seguida, criar uma
ligação simbólica para este arquivo em
/etc/rc3.d como S99postgresql.
Quando o servidor está em execução, seu PID
é armazenado no arquivo postmaster.pid
no diretório de dados.
Isto é feito para evitar que várias instâncias do servidor sejam
executadas no mesmo diretório de dados, e também pode ser usado
para parar o servidor.
Existem vários motivos comuns pelos quais o servidor pode falhar ao iniciar. Verifique o arquivo de log do servidor, ou inicie-o manualmente (sem redirecionar a saída padrão ou de erro padrão), e veja quais mensagens de erro aparecem. Abaixo, são explicadas com mais detalhes algumas mensagens de erro mais comuns.
LOG: não foi possível associar o endereço IPv4. "127.0.0.1": ↵
Endereço já em uso
DICA: Existe outro postmaster em execução na porta 5432?
Se não houver, aguarde alguns segundos e tente novamente.
FATAL: não foi possível criar nenhum soquete TCP/IP.
Esta mensagem geralmente significa exatamente o que sugere: tentou-se iniciar outro servidor na mesma porta em que um servidor já está em execução. Entretanto, se a mensagem de erro não for “Address already in use” (Endereço já em uso), ou alguma variante disso, pode haver um problema diferente. Por exemplo, tentar iniciar um servidor em um número de porta reservado pode produzir algo como:
$ postgres -p 666
LOG: não foi possível associar o endereço IPv4. "127.0.0.1": ↵
Permissão negada
DICA: Existe outro postmaster em execução na porta 666? ↵
Se não houver, aguarde alguns segundos e tente novamente.
FATAL: não foi possível criar nenhum soquete TCP/IP.
Uma mensagem como
FATAL: Não foi possível criar o segmento de memória compartilhada: ↵
Argumento inválido
DETALHE: A chamada de sistema falhou: ↵
shmget(chave=5440001, tamanho=4011376640, 03600).
provavelmente significa que o limite para o tamanho da memória
compartilhada do núcleo é menor do que a área de trabalho que o
PostgreSQL está tentando criar
(4011376640 bytes neste exemplo).
Só acontece se tiver sido definido
shared_memory_type como sysv.
Neste caso, pode-se tentar iniciar o servidor com um número de
buffers menor que o normal (shared_buffers),
ou reconfigurar o núcleo para aumentar o tamanho permitido da
memória compartilhada.
Também pode ser vista esta mensagem ao tentar iniciar vários
servidores na mesma máquina, se o espaço total solicitado exceder
o limite do núcleo.
Um erro como
FATAL: Não foi possível criar semáforos: ↵
Não há espaço disponível no dispositivo.
DETALHE: A chamada de sistema que falhou foi semget(5440126, 17, 03600).
não significa que se está sem espaço em disco. Significa que o limite do número de semáforos do núcleo do System V é menor do que o número que o PostgreSQL deseja criar. Como acima, este problema pode ser contornado iniciando o servidor com um número reduzido de conexões permitidas (max_connections), mas no longo prazo vai se desejar aumentar o limite do núcleo.
Detalhes sobre como configurar os recursos do IPC (Interprocess Communication) do System V são fornecidos em Memória compartilhada e semáforos.
Embora as condições de erro possíveis no lado cliente sejam bastante variadas e dependentes da aplicação, algumas delas podem estar diretamente relacionadas à forma como o servidor foi iniciado. Condições diferentes das mostradas a seguir devem estar documentadas com a respectiva aplicação cliente.
psql: erro: conexão com o servidor "server.joe.com" (123.123.123.123) ↵
porta 5432 falhou: Tempo esgotado para conexão
O servidor está em execução neste hospedeiro e aceitando ↵
conexões TCP/IP?
Esta é uma falha genérica do tipo “Não consegui encontrar o servidor para conversar”. Se parece com a mostrada acima quando é tentada a comunicação via TCP/IP. Um erro comum é esquecer de configurar listen_addresses para permitir para que o servidor aceite conexões TCP remotas.
Outra possibilidade é receber a mensagem abaixo, ao tentar a comunicação usando o soquete de domínio Unix para o servidor local:
psql: erro: conexão com o servidor no soquete "/tmp/.s.PGSQL.5432" falhou: ↵
Arquivo ou diretório não existe
O servidor está em execução neste hospedeiro e aceitando ↵
conexões neste soquete?
Se o servidor estiver realmente em execução, verifique se a ideia
do cliente sobre o caminho do soquete (aqui /tmp)
está em acordo com a configuração
unix_socket_directories do servidor.
Uma mensagem de falha de conexão sempre mostra o endereço do servidor, ou o nome do caminho do soquete, o que é útil para verificar se o cliente está tentando se conectar ao local correto. Se de fato não existir nenhum servidor escutando neste endereço, a mensagem de erro do núcleo normalmente será Conexão recusada ou Não existe tal arquivo ou diretório, conforme mostrado. (É importante perceber que Conexão recusada neste contexto não significa que o servidor recebeu a solicitação de conexão e a rejeitou. Este caso produz uma mensagem diferente, conforme mostrado em Problemas de autenticação.) Outras mensagens de erro, como Tempo esgotado, podem indicar problemas mais fundamentais, como falta de conectividade de rede, ou um firewall bloqueando a conexão.