Avant qu'une personne ait accès à la base de données, vous devez démarrer
le serveur de bases de données. Le programme serveur est appelé
postgres.
Si vous utilisez une version pré-packagé de PostgreSQL, il inclut pratiquement à coup sûr de quoi exécuter le serveur en tâche de fond suivant les conventions de votre système d'exploitation. Utiliser l'infrastructure du paquet pour démarrer le serveur demande beaucoup moins d'efforts qu'essayer de le faire soi-même. Consultez la documentation du paquet pour les détails.
La façon brute pour démarrer le serveur manuellement est d'invoquer
postgres directement, en précisant l'emplacement du
répertoire des données avec l'option -D, par
exemple :
$ postgres -D /usr/local/pgsql/data
qui laissera le serveur s'exécuter en avant plan. Pour cela, vous devez
être connecté en utilisant le compte de l'utilisateur
PostgreSQL. Sans l'option -d,
le serveur essaiera d'utiliser le répertoire de données nommé par la
variable d'environnement pgdata. Si cette variable ne le
fournit pas non plus, le lancement échouera.
Habituellement, il est préférable de lancer postgres en tâche
de fond. Pour cela, utilisez la syntaxe shell Unix habituelle :
$ postgres -D /usr/local/pgsql/data >journaux_trace 2>&1 &Il est important de sauvegarder les sorties stdout et stderr du serveur quelque part, comme montré ci-dessus. Cela vous aidera dans des buts d'audits ou pour diagnostiquer des problèmes (voir la Section 25.3 pour une discussion plus détaillée de la gestion de journaux de trace).
Le programme postgres prend aussi un certain nombre d'autres
options en ligne de commande. Pour plus d'informations, voir la page de
référence postmaster ainsi que le Chapitre 20 ci-dessous.
Cette syntaxe shell peut rapidement devenir ennuyante. Donc, le programme d'emballage pg_ctl est fourni pour simplifier certaines tâches. Par exemple :
pg_ctl start -l journaux_trace
lancera le serveur en tâche de fond et placera les sorties dans le journal
de trace indiqué. L'option -d a la même signification ici
que pour postgres. pg_ctl est aussi
capable d'arrêter le serveur.
Normalement, vous lancerez le serveur de bases de données lors du démarrage
de l'ordinateur . Les scripts de lancement
automatique sont spécifiques au système d'exploitation. Quelques scripts
d'exemple sont distribués avec PostgreSQL dans
le répertoire contrib/start-scripts. En installer un
nécessitera les droits de root.
Différents systèmes ont différentes conventions pour lancer les démons au
démarrage. La plupart des systèmes ont un fichier
/etc/rc.local ou
/etc/rc.d/rc.local. D'autres utilisent les répertoires
init.d ou rc.d. Quoi que
vous fassiez, le serveur doit être exécuté par le
compte utilisateur PostgreSQL et non pas
par root ou tout autre utilisateur. Donc, vous devriez
probablement former vos commandes en utilisant su postgres -c '...' .
Par exemple :
su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'
Voici quelques suggestions supplémentaires par système d'exploitation (dans chaque cas, assurez-vous d'utiliser le bon répertoire d'installation et le bon nom de l'utilisateur où nous montrons des valeurs génériques).
Pour freebsd, regardez le fichier
contrib/start-scripts/freebsd du répertoire des
sources de PostgreSQL.
Sur openbsd, ajoutez les lignes suivantes à
votre fichier /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
Sur les systèmes linux, soit vous ajoutez
/usr/local/pgsql/bin/pg_ctl start -l journaux_trace -D /usr/local/pgsql/data
à /etc/rc.d/rc.local ou
/etc/rc.local soit vous jetez un œil à
contrib/start-scripts/linux dans le répertoire des
sources de PostgreSQL.
Si vous utilisez systemd, vous pouvez utiliser
le fichier de service (par exemple dans
/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
Utiliser Type=notify nécessite que le binaire du
serveur soit construit avec configure --with-systemd.
Faites bien attention au paramètre de délai.
systemd a un délai par défaut de 90 secondes
(au moment de l'écriture de cette documentation) et tuera un processus
qui n'indique pas sa disponibilité après ce délai. Cependant, un serveur
PostgreSQL qui aurait à réaliser une
restauration suite à un crash pourrait prendre beaucoup plus de temps à
démarrer. La valeur suggérée, infinity, désactive ce
comportement.
Sur netbsd, vous pouvez utiliser les scripts de lancement de freebsd ou de linux suivant vos préférences.
Sur solaris, créez un fichier appelé
/etc/init.d/PostgreSQL et contenant la ligne
suivante :
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l journaux_trace -D /usr/local/pgsql/data"
Puis, créez un lien symbolique vers lui dans /etc/rc3.d de
nom s99PostgreSQL.
Tant que le serveur est lancé, son
pid est stocké dans le fichier
postmaster.pid du répertoire de données. C'est utilisé
pour empêcher plusieurs instances du serveur d'être exécutées dans le même
répertoire de données et peut aussi être utilisé pour arrêter le processus
le serveur.
Il existe de nombreuses raisons habituelles pour lesquelles le serveur échouerait au lancement. Vérifiez le journal des traces du serveur ou lancez-le manuellement (sans redirection des sorties standard et d'erreur) et regardez les messages d'erreurs qui apparaissent. Nous en expliquons certains ci-dessous parmi les messages d'erreurs les plus communs.
LOG: could not bind IPv4 address "127.0.0.1": Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. FATAL: could not create any TCP/IP sockets
Ceci signifie seulement ce que cela suggère : vous avez essayé de lancer
un autre serveur sur le même port où un autre est en
cours d'exécution. Néanmoins, si le message d'erreur du noyau
n'est pas address already in use ou une
quelconque variante, il pourrait y avoir un autre problème. Par
exemple, essayer de lancer un serveur sur un numéro
de port réservé pourrait avoir ce résultat :
$ postgres -p 666
LOG: could not bind IPv4 address "127.0.0.1": Permission denied
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL: could not create any TCP/IP sockets
Un message du type
FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
signifie probablement que les limites de votre noyau sur la taille de
la mémoire partagée est plus petite que l'aire de fonctionnement que
PostgreSQL essaie de créer (4011376640 octets
dans cet exemple). Ceci n'est susceptible de se produire uniquement si
shared_memory_type a été affecté à sysv. Dans ce
cas, vous pouvez essayer de lancer le serveur avec un nombre de tampons
plus petit que la normale
(shared_buffers) ou vous pouvez
reconfigurer votre noyau pour accroître la taille de mémoire partagée
autorisée. Vous pourriez voir aussi ce message en essayant d'exécuter
plusieurs serveurs sur la même machine si le total de l'espace qu'ils
requièrent dépasse la limite du noyau.
Une erreur du type
FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(5440126, 17, 03600).
ne signifie pas qu'il vous manque de l'espace disque. Elle signifie que la limite de votre noyau sur le nombre de sémaphores system v est inférieure au nombre que PostgreSQL veut créer. Comme ci-dessus, vous pouvez contourner le problème en lançant le serveur avec un nombre réduit de connexions autorisées (max_connections) mais vous voudrez éventuellement augmenter la limite du noyau.
Des détails sur la configuration des capacités IPC System V sont donnés dans la Section 19.4.1.
Bien que les conditions d'erreurs possibles du côté client sont assez variées et dépendantes de l'application, certaines pourraient être en relation direct avec la façon dont le serveur a été lancé. Les conditions autres que celles montrées ici devraient être documentées avec l'application client respective.
psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
Ceci est l'échec générique « je n'ai pas trouvé de serveur à qui parler ». Cela ressemble au message ci-dessus lorsqu'une connexion TCP/IP est tentée. Une erreur commune est d'oublier de configurer le serveur pour qu'il autorise les connexions TCP/IP.
Autrement, vous obtiendrez ceci en essayant une communication de type socket de domaine Unix vers un serveur local :
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?
Si le serveur est vraiment en cours d'exécution, vérifiez que le chemin
du socket pour le client (ici /tmp) est en accord
avec le paramètre unix_socket_directories du
serveur.
Un message d'échec de connexion affiche toujours l'adresse du serveur ou
le chemin de la socket, ce qui est utile pour vérifier que le client est
en train de se connecter au bon endroit. Si aucun serveur n'est en
écoute ici, le message d'erreur du noyau sera typiquement soit
connection refused soit
no such file or directory, comme ce qui
est illustré (il est important de réaliser que
connection refused, dans ce contexte,
ne signifie pas que le serveur a obtenu une demande
de connexion et l'a refusé. Ce cas produira un message différent comme
indiqué dans la Section 21.15).
D'autres messages d'erreurs tel que connection timed
out pourraient indiquer des problèmes plus fondamentaux
comme un manque de connexion réseau, ou un pare-feu bloquant la
connexion.