| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Avance rapide | Suivant | |
postmaster [-A 0 | 1 ] [-B nombre_de_tampons] [-c nom=valeur] [-d niveau_de_débogage] [-D répertoire_données] [-F] [-h nom_hôte] [-i] [-k répertoire] [-l] [-N nombre_max_connexions] [-o options_supplémentaires] [-p port] [-S] [--nom=valeur] [-n | -s]
postmaster est le serveur de bases de données multi-utilisateurs PostgreSQL. Pour qu'une application cliente accède à une base de données, elle se connecte (via le réseau ou localement) à un postmaster en cours d'exécution. Ensuite, le postmaster lance un processus serveur séparé (<< postgres >>) pour gérer la connexion. Le postmaster gère aussi la communication entre les processus du serveur.
Par défaut, le postmaster se lance en avant plan et affiche les messages des traces dans le flux standard des erreurs. En pratique, le postmaster devrait être lancé comme processus d'arrière-plan, par exemple au démarrage.
Un postmaster gère toujours les données à partir d'exactement un groupe de bases de données. Ce groupe est une collection de bases de données qui sont stockées à un emplacement commun du système de fichiers (l'<< aire des données >>). Plus d'un processus postmaster peut se lancer sur un système à la fois, s'ils utilisent des aires de données et des ports différents (voir ci-dessous). Une aire de données est créée avec initdb.
Quand le postmaster se lance, il a besoin de connaître l'emplacement de l'aire des données. L'emplacement doit être indiqué avec l'option -D ou la variable d'environnement PGDATA ; il n'existe pas de valeur par défaut. Typiquement, -D ou PGDATA pointe directement vers le répertoire des données créé par initdb. D'autres configurations possibles du fichier sont discutées dans Section 16.4.1.
postmaster accepte les arguments suivants en ligne de commande. Pour une discussion détaillée des options, consultez Section 16.4. Vous pouvez aussi sauvegarder une saisie de la plupart des options en initialisant un fichier de configuration.
Active les vérifications d'assertion en exécution, qui est une aide de débogage pour détecter les erreurs de programmation. Cette option est seulement disponible si elle était activée lors de la compilation de PostgreSQL. Dans ce cas, la valeur par défaut est << on >>.
Initialise le nombre de tampons partagés utilisés par les processus serveur. La valeur par défaut de ce paramètre est choisi par initdb ; référez-vous à Section 16.4.3.1 pour plus d'informations.
Configure un paramètre d'exécution. Les paramètres de configuration supportés par PostgreSQL sont décrits dans Section 16.4. La plupart des autres options en ligne de commande sont en fait des formes courtes de ces affectations de paramètres. -c peut apparaître plusieurs fois pour initialiser plusieurs paramètres.
Initialise le niveau de débogage. Plus cette valeur est haute, plus la sortie de débogage est importante. Les valeurs vont de 1 to 5.
Spécifie l'emplacement dans le système de fichiers du répertoire de données et des fichiers de configuration. Voir Section 16.4.1 pour plus de détails.
Désactive les appels à fsync. Cela permet une amélioration
des performances mais fait prendre le risque d'une corruption de données en cas
d'arrêt brutal du système. Cette option est équivalente à désactiver le
paramètre de configuration fsync. Lire la
documentation détaillée avant d'utiliser ceci !
--fsync=true a l'effet contraire de cette option.
Spécifie le nom d'hôte ou l'adresse IP sur lequel le postmaster est en attente de connexions TCP/IP provenant des applications clientes. La valeur peut aussi être une liste d'adresses séparées par des virgules ou * pour indiquer d'écouter sur toutes les interfaces disponibles. Une valeur vide indique de ne pas écouter les adresses IP, auquel cas seuls les sockets de domaine Unix peuvent être utilisés pour se connecter au postmaster. Par défaut, écoute seulement sur localhost. Spécifier cette option est équivalent à configurer le paramètre listen_addresses.
Autorise la connexion TCP/IP (Internet domain) des clients distants. Sans cette option, seules les connexions locales sont acceptées. Cette option correspond à la configuration tcpip_socket=true dans postgresql.conf.
Cette option est obsolète car elle ne permet pas d'accéder à toutes les possibilités de listen_addresses. Il est généralement préférable de configurer listen_addresses directement.
Spécifie le répertoire du socket de domaine Unix sur lequel le postmaster écoute les connexions des applications clientes. La valeur par défaut est normalement /tmp mais peut être modifiée au moment de la construction.
Active les connexions sécurisées utilisant SSL. PostgreSQL doit avoir été compilé avec le support de SSL pour que cette option soit disponible. Pour plus d'informations sur l'utilisation de SSL, référez-vous à Section 16.8.
Initialise le nombre maximum de connexions clientes que ce postmaster accepte. Par défaut, cette valeur est 32 mais il peut être initialisé aussi haut que ce que votre système supporte. (Notez que -B doit être au moins deux fois la valeur de -N. Voir Section 16.5 pour une discussion des besoins de ressources système pour un grand nombre de connexions clientes.) Spécifier cette option est équivalent à configurer le paramètre max_connections.
Les options spécifiées en ligne de commande dans options_supplémentaires sont passées à tous les processus serveur lancés par ce postmaster. Voir postgres pour les possibilités. Si la chaîne d'option contient des espaces, la chaîne entière doit être entre guillemets.
Spécifie le port TCP/IP ou l'extension du fichier socket de domaine Unix local sur lequel écoute le postmaster pour la connexion des applications clientes. A pour défaut la valeur de la variable d'environnement PGPORT ou, si PGPORT n'est pas configurée, alors il a pour valeur par défaut la valeur établie lors de la compilation (normalement 5432). Si vous spécifiez un port autre que celui par défaut, alors toutes les applications clientes doivent spécifier le même port en utilisant soit les options en ligne de commande soit PGPORT.
Spécifie que le processus postmaster doit se lancer en mode silencieux. C'est-à-dire qu'il est dissocié du terminal (de contrôle) de l'utilisateur, lancé dans son propre groupe de processus et redirige sa propre sortie standard et sa propre sortie standard des erreurs vers /dev/null.
Utiliser cette option désactive tous les messages de traces, ce qui n'est probablement pas ce que vous souhaitez car cela rend le débogage très difficile. Voir ci-dessous un meilleur moyen de lancer postmaster en tâche de fond.
--silent-mode=false a l'effet opposé de cette option.
Initialise un paramètre nommé en exécution ; une forme courte de -c.
Deux options supplémentaires en ligne de commande sont disponibles pour les débogages de problèmes causant l'arrêt anormal d'un processus de serveur. La stratégie ordinaire dans cette situation est de notifier tous les autres processus serveur qu'ils doivent se terminer et réinitialiser ensuite la mémoire partagée et les sémaphores. Ceci est dû au fait qu'un processus serveur errant peut avoir corrompu quelques états partagés avant de se terminer. Ces options sélectionnent des comportements alternatifs de postmaster dans cette situation. Aucune de ces options n'a pour but d'être utilisée ordinairement.
Ces options spéciales sont :
postmaster réinitialise les structures de données partagées. Un développeur système ayant les connaissances nécessaires peut alors utiliser un débogueur pour examiner l'état des mémoires partagées et des sémaphores.
postmaster stoppe tous les autres processus serveur en envoyant le signal SIGSTOP mais ne les termine pas. Ceci permet à un développeur système de récupérer manuellement les << core dump >> à partir de tous les processus serveur.
Codage des caractères par défaut utilisé par les clients. (Les clients peuvent surcharger ceci individuellement.) Cette valeur peut aussi être dans le fichier de configuration.
Emplacement par défaut du répertoire de données.
Valeur par défaut du paramètre d'exécution datestyle. (L'utilisation de cette variable d'environnement est obsolète.)
Port par défaut (de préférence, initialisé dans le fichier de configuration)
Fuseau horaire du serveur
Un message d'échec mentionnant semget ou shmget indique probablement que vous avez besoin de configurer votre noyau pour fournir les mémoires partagées et sémaphores adéquats. Pour plus de discussion, voir Section 16.5.
Astuce : Vous pouvez peut-être éviter de reconfigurer votre noyau en décrémentant shared_buffers pour réduire la consommation de mémoire partagée de PostgreSQL et/ou en réduisant max_connections pour réduire la consommation de sémaphores.
Un message d'échec suggérant qu'un autre postmaster est en cours d'exécution doit être vérifié avec attention, par exemple en utilisant la commande
$ ps ax | grep postmaster
ou
$ ps -ef | grep postmaster
suivant votre système. Si vous êtes certain qu'aucun postmaster en conflit n'est en cours d'exécution, vous pouvez supprimer le fichier verrou mentionné dans le message et tenter de nouveau.
Un message d'échec indiquant l'incapacité à lier un port peut indiquer que ce port est déjà utilisé par un processus autre que le serveur PostgreSQL. Vous pouvez obtenir cette erreur si vous terminez le postmaster et si vous le relancez immédiatement en utilisant le même port ; dans ce cas, vous devez simplement attendre quelques secondes jusqu'à ce que le système d'exploitation ferme le port avant de réessayer. Enfin, vous pouvez obtenir cette erreur si vous spécifiez un numéro de port que votre système d'exploitation considère comme réservé. Par exemple, un grand nombre de versions d'Unix considèrent que les numéros de port inférieurs à 1024 sont << de confiance >> et permettent seulement au superutilisateur Unix d'y accéder.
Si c'est possible, ne pas utiliser SIGKILL pour tuer le processus postmaster. L'utilisation de SIGKILL empêche postmaster de libérer les ressources du système (c'est-à-dire les mémoires partagées et les sémaphores) qu'il détient avant de terminer. Ceci peut causer des problèmes de lancement d'un processus nouveau postmaster.
Pour terminer normalement postmaster, les signaux SIGTERM, SIGINT ou SIGQUIT peuvent être utilisés. Le premier attend l'arrêt de tous les clients avant de quitter, le second déconnecte de force tous les clients et le troisième quitte immédiatement sans arrêt propre ce qui donne lieu à une opération de récupération lors du redémarrage. Le signal SIGHUP recharge les fichiers de configuration du serveur.
L'utilitaire pg_ctl peut être utilisé pour démarrer et arrêter le postmaster en toute sûreté et confortablement.
Les options -- ne fonctionnent pas sur FreeBSD ou OpenBSD. Utilisez -c à la place. Ceci est un bogue dans les systèmes d'exploitation affectés ; une prochaine version de PostgreSQL fournit un contournement si ceci n'est pas corrigé.
Pour lancer postmaster en tâche de fond en utilisant les valeurs par défaut, saisissez :
$ nohup postmaster >logfile 2>&1 </dev/null &
Pour lancer postmaster sur un port spécifique :
$ postmaster -p 1234
Cette commande lance un postmaster communiquant via le port 1234. Pour se connecter à ce postmaster en utilisant psql, il faut lancer par exemple
$ psql -p 1234
ou initialiser la variable d'environnement PGPORT :
$ export PGPORT=1234 $ psql
Les paramètres d'exécution nommés peuvent être configurés avec un des styles suivants :
$ postmaster -c work_mem=1234 $ postmaster --work-mem=1234
Chaque forme surcharge le paramétrage pouvant exister pour work_mem dans postgresql.conf. Notez que les tirets bas dans les noms de paramètre peuvent être écrits soit avec un tiret bas soit avec un tiret sur la ligne de commande.
Astuce : Sauf dans le cas d'expérimentations à court terme, il est conseillé d'éditer le paramétrage dans postgresql.conf plutôt que d'utiliser les options de ligne de commande pour configurer un paramètre.
| Précédent | Sommaire | Suivant |
| postgres | Niveau supérieur | Internes |