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. Le
programme postgres doit savoir où trouver les données qu'il est
supposé utiliser. Ceci se fait avec l'option -d. Du coup, la
façon la plus simple de lancer le serveur est :
$ 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 24.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 19 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. Certains sont distribués avec
PostgreSQL dans le répertoire
contrib/start-scripts. En installer un demandera 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). Ou il pourrait signifier que vous n'avez pas du tout configuré le support de la mémoire partagée de type System-V dans votre noyau. Comme contournement temporaire, vous pouvez essayer de lancer le serveur avec un nombre de tampons plus petit que la normale (shared_buffers). Éventuellement, 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.
Si vous obtenez une erreur « illegal system call », il est probable que la mémoire partagée ou les sémaphores ne sont pas du tout supportés par votre noyau. Dans ce cas, votre seule option est de reconfigurer le noyau pour activer ces fonctionnalités.
Des détails sur la configuration des capacités IPC System V sont donnés dans la Section 18.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: could not connect to server: Connection refused
Is the server running on host "server.joe.com" and accepting
TCP/IP connections on port 5432?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: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
La dernière ligne est utile pour vérifier si le client essaie de se
connecter au bon endroit. Si aucun serveur n'est exécuté 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 20.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.