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 23.3, « Maintenance du fichier de traces » 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(1) ainsi que le Chapitre 18, Configuration du serveur ci-dessous.
Cette syntaxe shell peut rapidement devenir ennuyante. Donc, le programme d'emballage pg_ctl(1) 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 :
Créer un groupe de base
de données
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™.
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 socket: 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 TCP/IP listen socket
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 socket: Permission denied HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry. FATAL: could not create TCP/IP listen socket
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 17.4.1, « Mémoire partagée et sémaphore ».
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 19.4, « Problèmes d'authentification »). D'autres messages d'erreurs tel que connection timed out pourraient indiquer des problèmes plus fondamentaux comme un manque de connexion réseau.