Ce document chapitre décrit l'installation de PostgreSQL™ à partir du code source. (Ce document chapitre peut être ignoré lors de l'installation d'une distribution pré-empaquetée, paquet RPM ou Debian, par exemple. Il est alors plus utile de lire les instruction du mainteneur du paquet.)
./configure gmake su gmake install adduser postgres mkdir /usr/local/pgsql/data chown postgres /usr/local/pgsql/data su - postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 & /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test
Le reste du document chapitre est la version longue.
En général, les plateformes style unix modernes sont capables d'exécuter PostgreSQL™. Les plateformes sur lesquelles des tests ont été effectués sont listées dans la Section 1.9, « Plateformes supportées » ci-après. Dans le répertoire doc de la distribution, il y a plusieurs FAQ spécifiques à des plateformes particulières à consulter en cas de difficultés.
Les logiciels suivants sont nécessaires pour compiler PostgreSQL™ :
GNU make est nécessaire ; les autres programmes make ne fonctionnent pas. GNU make est souvent installé sous le nom gmake ; ce document y fait toujours référence sous ce nom (sur certains système, GNU make est l'outil par défaut et est nommé make). Pour connaître la version utilisée, saisir
gmake --version
Il est recommandé d'avoir une version postérieure à la version 3.76.1.
Il est nécessaire d'avoir un compilateur C ISO/ANSI. Une version récente de GCC™ est recommandée mais PostgreSQL™ est connu pour être compilable avec de nombreux compilateurs de divers vendeurs.
tar est requis pour déballer la distribution des sources, associé à gzip ou bzip2.
La bibliothèque GNU Readline™ est utilisée par défaut (pour faciliter l'édition des lignes et le parcours de l'historique des commandes). Pour ne pas l'utiliser, il faut préciser --without-readline au moment d'exécuter la commande configure. Une alternative possible est l'utilisation de la bibliothèqe libedit sous license BSD, développée au début sur NetBSD™. La bibliothèque libedit est compatible GNU Readline™ et est utilisée si cette dernière n'est pas trouvée ou si --with-libedit-preferred est utilisé sur la ligne de commande de configure. Lorsqu'une distribution Linux à base de paquets est utilisée, si les paquets readline et readline-devel sont séparés, il faut impérativement installer les deux.
La bibliothèque de compression zlib™ est utilisée par défaut. Pour ne pas l'utiliser, il faut préciser --without-zlib à configure. Cela a pour conséquence de désactiver le support des archives compressées dans pg_dump et pg_restore.
Les paquets suivants sont optionnels. Ils ne sont pas obligatoires lors d'une compilation par défaut, mais le deviennent lorsque certaines options sont utilisées, comme cela est expliqué par la suite.
Pour installer le langage procédural PL/Perl, une installation complète de Perl™, comprenant la bibliothèque libperl et les fichiers d'en-tête, est nécessaire.
Comme PL/Perl est une bibliothèque partagée, la bibliothèque libperl doit aussi être partagée sur la plupart des plateformes. C'est désormais le choix par défaut dans les version récente de Perl™, mais ne l'était pas dnas les versions plus anciennes. Dans tous les cas, c'est du ressort de celui qui installe Perl. Si vous avez l'intention d'avoir plus qu'une utilisation occasionnelle de PL/Perl, vous devez vous assurer que l'installation de Perl™ a été faite avec l'option usemultiplicity activée (perl -V vous indiquera si c'est le cas).
Si la bibliothèque partagée, nécessaire, n'est pas présente, un message d'avertissement tel que celui qui suit apparaît à la compilation :
*** Cannot build PL/Perl because libperl is not a shared library. *** You might have to rebuild your Perl installation. Refer to *** the documentation for details.
(Si la sortie écran est ignorée, on peut constater que la bibliothèque plperl.so de PL/Perl, ou similaire, n'est pas installée.) Si ce message est affiché, il faut recompiler et réinstaller Perl™ manuellement pour pouvoir compiler PL/Perl. Lors de la phase de configuration de Perl™, il faut demander une bibliothèque partagée.
Pour compiler le langage de programmation serveur PL/Python, il faut que Python™ soit installé avec les fichiers d'en-tête et le module distutils. Le module distutils est inclus par défaut avec Python™ 1.6 et les versions suivantes ; les utilisateurs des versions précédentes de Python™ doivent l'installer.
Puisque PL/Python doit être une bibliothèque partagée, la bibliothèque libpython doit l'être aussi sur la plupart des plateformes. Ce n'est pas le cas des installations par défaut de Python. Si, après la compilation et l'installation, il existe un fichier nommé plpython.so (des extensions différentes sont possibles), tout va bien. Sinon, il est fort probable qu'un avertissement semblable à celui qui suit soit apparu :
*** Cannot build PL/Python because libpython is not a shared library. *** You might have to rebuild your Python installation. Refer to *** the documentation for details.
Ce qui signifie qu'il faut recompiler (une partie de) Python™ pour créer cette bibliothèque partagée.
En cas de problèmes, on peut exécuter le configure de Python™ 2.3 ou ultérieur en utilisant le commutateur --enable-shared. Sur certains systèmes d'exploitation, il n'est pas nécessaire de construire une bibliothèque partagée, mais il faut en convaincre le système de construction de PostgreSQL™. Le fichier Makefile du répertoire src/pl/plpython donne des détails complémentaires.
Pour construire le langage de procédure PL/Tcl, Tcl™ doit être installé. Si une version antérieure à la version 8.4 de Tcl™, est utilisée, on s'assurera qu'il a été construit sans le support du multi-thread.
Pour activer le support de langage natif (NLS), qui permet d'afficher les messages d'un programme dans une langue autre que l'anglais, une implantation de l'API Gettext est nécessaire. Certains systèmes d'exploitation l'intégrent (par exemple, Linux, NetBSD, Solaris). Pour les autres systèmes, un paquet additionnel peut être téléchargé sur http://developer.postgresql.org/~petere/bsd-gettext. Pour utiliser l'implantation Gettext des bibliothèques C GNU, certains utilitaires nécessitent le paquet GNU Gettext™. Il n'est pas nécessaire dans les autres implantations.
Kerberos, OpenSSL™, OpenLDAP™ ou PAM pour bénéficier de l'authentification ou du chiffrement en utilisant ces services.
En cas de compilation à partir d'une arborescence Git et non d'un paquet de sources publié, ou pour faire du développement au niveau serveur, les paquets suivants seront également nécessaires :
GNU Flex et Bison sont nécessaires pour compiler à partir d'un export du Git ou lorsque les fichiers de définition de l'analyseur ou du « scanner » sont modifiés. Les versions nécessaires sont Flex 2.5.4 ou ultérieure et Bison 1.875 ou ultérieure. D'autres programmes yacc peuvent parfois être utilisés, mais cela est déconseillé, au regard des efforts supplémentaires que cela demande. Tout autre programme lex ne fonctionne pas.
Si d'autres paquets GNU sont nécessaires, ils peuvent être récupérés sur un site miroir de GNU (voir http://www.gnu.org/order/ftp.html pour la liste) ou sur ftp://ftp.gnu.org/gnu/.
Il est important de vérifier qu'il y a suffisamment d'espace disque disponible. 65 Mo sont nécessaires pour la compilation et 15 Mo pour le répertoire d'installation. Un groupe de bases de données vide nécessite 25 Mo ; les fichiers des bases prennent cinq fois plus d'espace que des fichiers texte contenant les mêmes données. Si des tests de régression sont prévus, 90 Mo supplémentaires sont temporairement nécessaires. On peut utiliser la commande df pour vérifier l'espace disque disponible.
Les sources de PostgreSQL™ 8.3.23 peuvent être obtenues par ftp anonyme sur ftp://ftp.postgresql.org/pub/source/v8.3.23/postgresql-8.3.23.tar.gz. D'autres options de téléchargement sont possibles à partir du site web : http://www.postgresql.org/download/. Après avoir obtenu le fichier, on le décompresse :
gunzip postgresql-8.3.23.tar.gz tar xf postgresql-8.3.23.tar
Cela crée un répertoire postgresql-8.3.23 contenant les sources de PostgreSQL™ dans le répertoire courant. Le reste de la procédure d'installation s'effectue depuis ce répertoire.
Ces instructions supposent que l'installation existante se trouve dans le répertoire /usr/local/pgsql, et que l'aire de données est dans /usr/local/pgsql/data. Il convient de modifier ces chemins en fonction de l'installation actuelle.
Le format de stockage interne des données change typiquement à chaque version majeure de PostgreSQL™. C'est pourquoi, lors de la mise à jour d'une installation qui n'est pas du numéro de version « 8.3.x », il faut sauvegarder et restaurer ses données. Lors d'une mise à jour à partir de PostgreSQL™ « 8.3.x », la nouvelle version peut utiliser les fichiers de données actuels ; les étapes de sauvegarde et de restauration ci-dessous, inutiles, peuvent être ignorées.
Lors de la sauvegarde, il est préférable de s'assurer que la base de données n'est pas actualisée. Non que cela affecte l'intégrité de la sauvegarde, mais parce que les données modifiées ne sont pas incluses. Il peut, dans ce cas, être nécessaire d'éditer les permissions dans le fichier /usr/local/pgsql/data/pg_hba.conf (ou équivalent) pour interdire les accès autres que celui utile à la sauvegarde.
Pour sauvegarder la base, saisir :
pg_dumpall > fichierdesortie
Pour conserver les identifiants d'objets (OID) (lorsqu'ils sont utilisés comme clé étrangère), utiliser l'option -o lors de l'exécution de pg_dumpall.
Pour effectuer la sauvegarde, il est possible d'utiliser la commande pg_dumpall incluse dans la distribution de la version actuelle. Cependant, pour de meilleurs résultats, il est préférable d'utiliser la commande pg_dumpall contenue dans PostgreSQL™ 8.3.23 puisqu'elle corrige les erreurs des versions précédentes. Bien que ce conseil puisse paraître absurde, tant que la nouvelle version n'est pas installée, il convient de le suivre si l'objectif est d'installer la nouvelle version en parallèle de l'ancienne. Dans ce cas, il est possible de terminer normalement l'installation et de transférer les données dans un second temps, ce qui réduit l'indisponibilité.
Arrêter l'ancien serveur :
pg_ctl stop
Sur les systèmes qui lancent PostgreSQL™ au démarrage, il y a probablement un fichier de démarrage qui peut faire la même chose. Par exemple, sur un système Red Hat Linux, la commande
/etc/rc.d/init.d/postgresql stop
doit fonctionner.
En cas de restauration d'une sauvegarde, renommer ou supprimer l'ancien répertoire d'installation. Il est préférable de renommer le répertoire plutôt que de le supprimer, parce qu'en cas de problème, on peut avoir besoin d'y revenir. Le répertoire peut prendre beaucoup d'espace disque. Pour renommer le répertoire, utiliser une commande comme :
mv /usr/local/pgsql /usr/local/pgsql.old
Installer la nouvelle version de PostgreSQL™ comme indiquée dans la prochaine section Section 1.5, « Procédure d'installation ».
Créer un nouveau cluster de bases de données. Ces commandes doivent être exécutées sous le compte superutilisateur initial (qui existe déjà dans le cas d'une mise à jour).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Restaurer le pg_hba.conf précédent et toutes les modifications de postgresql.conf.
Lancer le serveur de bases de données, toujours à partir du compte superutilisateur :
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Enfin, restaurer les données à partir de la sauvegarde avec :
/usr/local/pgsql/bin/psql -d postgres -f outputfile
en utilisant le nouveau psql.
Des informations supplémentaires sont disponibles dans la documentation ???. Cette documentation contient notmamment des instructions sur la manière d'exécuter les deux versions en parallèle.
Configuration
La première étape de la procédure d'installation est de configurer l'arborescence des sources en fonction du système et de choisir les options souhaitées. Cela est obtenu en exécutant le script configure. Pour une installation par défaut, on tape simplement
./configure
Ce script exécute de nombreux tests afin de déterminer les valeurs de certaines variables dépendantes du système. Il détecte ainsi les particularités du système d'exploitation. Il crée divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a été trouvé. (Il est toujours possible d'exécuter configure à partir d'un répertoire extérieur à l'arborescence des sources pour séparer arborescence de compilation et arborescence des sources.)
La configuration par défaut compile le serveur et les utilitaires, ainsi que toute application cliente ou interface qui ne requière qu'un compilateur C. Tous les fichiers sont installés par défaut sous /usr/local/pgsql.
Les processus de compilation et d'installation peuvent être personnalisés par le passage d'une ou plusieurs options sur la ligne de commande après configure :
Installer tous les fichiers sous le répertoire PREFIX au lieu du répertoire /usr/local/pgsql. Les fichiers sont installés dans divers sous-répertoires ; aucun fichier n'est directement installé dans le répertoire PREFIX.
Pour satisfaire des besoins spécifiques, il est possible de personnaliser les sous-répertoires à l'aide des options suivantes. Toutefois, si ces options conservent leurs valeurs par défaut, il reste possible de relocaliser l'installation, le répertoire pouvant être déplacé après installation. (Cela n'affecte pas les emplacements de man et doc.)
Dans le cas d'installations déplaçables, utiliser l'option --disable-rpath de configure. De plus, il est nécessaire d'indiquer au système d'exploitation comment trouver les bibliothèques partagées.
Vous pouvez installer les fichiers dépendants de l'architecture dans un répertoire différent, EXEC-PREFIX, de celui donné par PREFIX. Ce qui peut être utile pour partager les fichiers dépendants de l'architecture entre plusieurs machines. Si vous l'omettez, EXEC-PREFIX est égal à PREFIX et les fichiers dépendants seront installés sous la même arborescence que les fichiers indépendants de l'architecture, ce qui est probablement ce que vous voulez.
Spécifie le répertoire des exécutables. Par défaut, il s'agit de EXEC-PREFIX/bin, ce qui signifie /usr/local/pgsql/bin.
Prépare le répertoire pour des fichiers de données en lecture seule utilisés par les programmes d'installation. Par défaut, il s'agit de PREFIX/share. Il est bon de noter que cela n'a rien à voir avec l'emplacement des fichiers de votre base de données.
Le répertoire contenant divers fichiers de configuration. Par défaut, il s'agit de PREFIX/etc.
L'endroit où installer les bibliothèques et les modules chargeables dynamiquement. Par défaut, il s'agit de EXEC-PREFIX/lib.
Le répertoire où sont installées les en-têtes C et C++. Par défaut, il s'agit de PREFIX/include.
Les pages man fournies avec PostgreSQL™ seront installées sous ce répertoire, dans leur sous-répertoire manx respectif. Par défaut, il s'agit de PREFIX/man.
Les fichiers de documentation, sauf les pages « man », seront installés dans ce répertoire. Par défaut, il s'agit de PREFIX/doc. Si l'option --without-docdir est spécifiée, la documentation ne sera pas installée par make install. Ceci est fait pour aider les scripts d'empaquetage ayant des méthodes particulières pour installer la documentation.
Une attention toute particulière a été prise afin de rendre possible l'installation de PostgreSQL™ dans des répertoires partagés (comme /usr/local/include) sans interférer avec des noms de fichiers relatifs au reste du système. En premier lieu, le mot « /postgresql » est automatiquement ajouté au répertoire datadir, sysconfdir et docdir, à moins que le nom du répertoire à partir de la racine contienne déjà le mot « postgres » où « pgsql ». Par exemple, si vous choisissez /usr/local comme préfixe, la documentation sera installée dans /usr/local/doc/postgresql, mais si le préfixe est /opt/postgres, alors il sera dans /opt/postgres/doc. Les fichiers d'en-têtes publiques C de l'interface cliente seront installés sous includedir et sont propres par rapport aux noms de fichiers relatifs au reste du système. Les fichiers d'en-têtes privés et les fichiers d'en-têtes du serveur sont installés dans des répertoires privés sous includedir. Voir la documentation de chaque interface pour savoir comment obtenir ces fichiers d'en-tête. Enfin, un répertoire privé sera aussi créé si nécessaire sous libdir pour les modules chargeables dynamiquement.
REPERTOIRES est une liste de répertoires séparés par des caractères deux points (:) qui sera ajoutée à la liste de recherche des fichiers d'en-tête. Si vous avez des paquetages optionnels (tels que Readline GNU) installés dans des répertoires non conventionnels, vous pouvez utiliser cette option et certainement l'option --with-libraries correspondante.
Exemple : --with-includes=/opt/gnu/include:/usr/sup/include.
REPERTOIRES est une liste de recherche de répertoires de bibliothèques séparés par des caractères deux points (:). Vous aurez probablement à utiliser cette option (et l'option correspondante --with-includes) si vous avez des paquetages installés dans des répertoires non conventionnels.
Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib.
Permet de mettre en place le support des langues natives (NLS). C'est la possibilité d'afficher les messages des programmes dans une langue autre que l'anglais. LANGUES est une liste de codes des langues que vous voulez supporter séparés par un espace. Par exemple, --enable-nls='de fr' (l'intersection entre votre liste et l'ensemble des langues traduites actuellement sera calculée automatiquement). Si vous ne spécifiez pas de liste, alors toutes les traductions disponibles seront installées.
Pour utiliser cette option, vous avez besoin d'une implémentation de l'API Gettext ; voir après.
Positionne NUMERO comme numéro de port par défaut pour le serveur et les clients. La valeur par défaut est 5432. Le port peut toujours être changé ultérieurement mais, si vous le faites ici, alors les exécutables du serveur et des clients auront la même valeur par défaut, ce qui est vraiment très pratique. Habituellement, la seule bonne raison de choisir une valeur autre que celle par défaut est que vous souhaitez exécuter plusieurs serveurs PostgreSQL™ sur la même machine.
Permet l'utilisation du langage de procédures PL/Perl côté serveur.
Permet la compilation du langage de procédures PL/Python.
Permet la compilation du langage de procédures PL/Tcl.
Tcl installe les fichiers tclConfig.sh, contenant certaines informations de configuration nécessaires pour compiler le module d'interfaçage avec Tcl. Ce fichier est trouvé automatiquement mais, si vous voulez utiliser une version différente de Tcl, vous pouvez spécifier le répertoire où le trouver.
Construire avec le support de l'authentification GSSAPI. Sur de nombreux systèmes, GSSAPI (qui fait habituellement partie d'une installation Kerberos) n'est pas installé dans un emplacement recherché par défaut (c'est-à-dire /usr/include, /usr/lib), donc vous devez utiliser les options --with-includes et --with-libraries en plus de cette option. configure vérifiera les fichiers d'en-têtes nécessaires et les bibliothèques pour s'assurer que votre installation GSSAPI est suffisante avant de continuer.
Compile le support d'authentification de Kerberos 5. Sur beaucoup de systèmes, le système Kerberos n'est pas installé à un emplacement recherché par défaut (c'est-à-dire /usr/include, /usr/lib), donc vous devez utiliser les options --with-includes et --with-libraries en plus de cette option. configure vérifiera les fichiers d'en-tête et les bibliothèques requis pour s'assurer que votre installation Kerberos est suffisante avant de continuer
Le nom par défaut du service principal de Kerberos (aussi utilisé par GSSAPI). postgres est pris par défaut. Il n'y a habituellement pas de raison de le changer sauf dans le cas d'un environnement Windows, auquel cas il doit être mis en majuscule, POSTGRES.
Compile le support de connexion SSL (chiffrement). Le paquetage OpenSSL™ doit être installé. configure vérifiera que les fichiers d'en-tête et les bibliothèques soient installés pour s'assurer que votre installation d'OpenSSL™ est suffisante avant de continuer.
Compile le support PAM (Modules d'Authentification Pluggable).
Demande l'ajout du support de LDAP pour l'authentification et la recherche des paramètres de connexion (voir la documentation sur l'authentification des clients et libpq??? et ???). Sur Unix, cela requiert l'installation du paquet OpenLDAP™. configure vérifiera l'existence des fichiers d'en-tête et des bibliothèques requis pour s'assurer que votre installation d'OpenLDAP™ est suffisante avant de continuer. Sur Windows, la bibliothèque WinLDAP™ est utilisée par défaut.
Évite l'utilisation de la bibliothèque Readline (et de celle de libedit). Cela désactive l'édition de la ligne de commande et l'historique dans psql, ce n'est donc pas recommandé.
Favorise l'utilisation de la bibliothèque libedit (sous licence BSD) plutôt que Readline (GPL). Cette option a seulement un sens si vous avez installé les deux bibliothèques ; dans ce cas, par défaut, Readline est utilisé.
Compile le support de Bonjour. Ceci requiert le support de Bonjour dans votre système d'exploitation. Recommandé sur Mac OS X.
Utilise la bibliothèque OSSP UUID lors de la construction du module contrib/uuid-ossp. Cette bibliothèque fournit des fonctions pour générer les UUID.
Construit avec libxml (active le support SQL/XML). Une version 2.6.23 ou ultérieure de libxml est requise pour cette fonctionnalité.
Libxml installe un programme xml2-config qui est utilisé pour détecter les options du compilateur et de l'éditeur de liens. PostgreSQL l'utilisera automatiquement si elle est trouvée. Pour indiquer une installation de libxml dans un emplacement inhabituel, vous pouvez soit configurer la variable d'environnement XML2_CONFIG pour pointer vers le programme xml2-config appartenant à l'installation, ou utiliser les options --with-includes et --with-libraries.
Utilise libxslt pour construire contrib/xml2. Le module contrib/xml2 se base sur cette bibliothèque pour réaliser les transformations XSL du XML.
Utilise le stockage des entiers sur 64 bits pour les types datetime et interval plutôt que le stockage par défaut en virgule flottante. Ceci réduit le nombre de valeurs représentatives mais garantit une précision à la microseconde sur toute l'échelle de valeurs (voir la la documentation sur les types de données date et heure??? pour plus d'informations).
Autorise le succès de la construction y compris lorsque PostgreSQL™ n'a pas le support spinlock du CPU pour la plateforme. Ce manque de support résultera en des performances faibles ; du coup, cette option devra seulement être utilisée si la construction échoue et vous informe du manque de support de spinlock sur votre plateforme. Si cette option est requise pour construire PostgreSQL™ sur votre plateforme, merci de rapporter le problème aux développeurs de PostgreSQL™.
Rend les bibliothèques clientes compatibles avec les threads. Ceci permet des threads concurrents dans les programmes libpq et ECPG ce qui leur permet de gérer en toute sûreté leur connexions privées. Cette option requiert un support adéquat des threads sur votre système d'exploitation.
PostgreSQL™ inclut sa propre base de données des fuseaux horaires, nécessaire pour les opérations sur les dates et les heures. Cette base de données est en fait compatible avec la base de fuseaux horaires « zic » fournie par de nombreux systèmes d'exploitation comme FreeBSD, Linux et Solaris, donc ce serait redondant de l'installer une nouvelle fois. Quand cette option est utilisée, la base des fuseaux horaires, fournie par le système, dans RÉPERTOIRE est utilisée à la place de celle inclus dans la distribution des sources de PostgreSQL. RÉPERTOIRE doit être indiqué avec un chemin absolu. /usr/share/zoneinfo est un répertoire très probable sur certains systèmes d'exploitation. Notez que la routine d'installation ne détectera pas les données de fuseau horaire différentes ou erronées. Si vous utilisez cette option, il vous est conseillé de lancer les tests de régression pour vérifier que les données de fuseau horaire que vous pointez fonctionnent correctement avec PostgreSQL™.
Cette option a pour cible les distributeurs de paquets binaires qui connaissent leur système d'exploitation. Le principal avantage d'utiliser cette option est que le package PostgreSQL n'aura pas besoin d'être mis à jour à chaque fois que les règles des fuseaux horaires changent. Un autre avantage est que PostgreSQL peut être cross-compilé plus simplement si les fichiers des fuseaux horaires n'ont pas besoin d'être construit lors de l'installation.
Évite l'utilisation de la bibliothèque Zlib. Cela désactive le support des archives compressées dans pg_dump et pg_restore. Cette option est seulement là pour les rares systèmes qui ne disposent pas de cette bibliothèque.
Compile tous les programmes et bibliothèques en mode de débogage. Cela signifie que vous pouvez exécuter les programmes via un débogueur pour analyser les problèmes. Cela grossit considérablement la taille des exécutables et, avec des compilateurs autres que GCC, habituellement, cela désactive les optimisations du compilateur, provoquant des ralentissements. Cependant, mettre ce mode en place est extrêmement utile pour repérer les problèmes. Actuellement, cette option est recommandée pour les installations en production seulement si vous utilisez GCC. Néanmoins, vous devriez l'utiliser si vous développez ou si vous utilisez une version béta.
En cas d'utilisation de GCC, tous les programmes et bibliothèques sont compilés pour qu'elles puissent être profilées. À la sortie du processus serveur, un sous-répertoire sera créé pour contenir le fichier gmon.out à utiliser pour le profilage. Cette option est à utiliser seulement avec GCC lors d'un développement.
Permet la vérification des assertions par le serveur qui teste de nombreux cas de conditions « impossibles ». Ce qui est inestimable dans le cas de développement, mais les tests peuvent ralentir sensiblement le système. Activer cette option n'influe pas sur la stabilité de votre serveur ! Les assertions vérifiées ne sont pas classées par ordre de sévérité et il se peut qu'un bogue anodin fasse redémarrer le serveur s'il y a un échec de vérification. Cette option n'est pas recommandée dans un environnement de production mais vous devriez l'utiliser lors de développement ou pour les versions béta.
Active la recherche automatique des dépendances. Avec cette option, les fichiers makefile sont appelés pour recompiler les fichiers objet dès qu'un fichier d'en-tête est modifié. C'est pratique si vous faites du développement, mais inutile si vous ne voulez que compiler une fois et installer. Pour le moment, cette option ne fonctionne qu'avec GCC.
Compile avec le support de l'outil de trace dynamique, DTrace. Le seul système d'exploitation supportant DTrace pour l'instant est Solaris.
Pour pointer vers le programme dtrace, la variable d'environnement DTRACE doit être configurée. Ceci sera souvent nécessaire car dtrace est typiquement installé sous /usr/sbin, qui pourrait ne pas être dans le chemin. Des options supplémentaires en ligne de commande peuvent être indiquées dans la variable d'environnement DTRACEFLAGS pour le programme dtrace.
Pour inclure le support de DTrace dans un exécutable 64-bit, ajoutez l'option DTRACEFLAGS="-64" pour configure. Par exemple, en utilisant le compilateur GCC :
./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
En utilisant le compilateur de Sun :
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
Si vous préférez utiliser un compilateur C différent de ceux listés par configure, positionnez la variable d'environnement CC pour qu'elle pointe sur le compilateur de votre choix. Par défaut, configure pointe sur gcc s'il est disponible, sinon il utilise celui par défaut de la plateforme (habituellement cc). De façon similaire, vous pouvez repositionner les options par défaut du compilateur à l'aide de la variable CFLAGS.
Vous pouvez spécifier les variables d'environnement sur la ligne de commande configure, par exemple :
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
Voici une liste des variables importantes qui sont configurables de cete façon :
compilateur C
options à passer au compilateur C
préprocesseur C
options à passer au préprocesseur C
emplacement du programme dtrace
options à passer au programme dtrace
options à passer à l'éditeur de liens
options de l'éditeur de liens pour la création des liens des bibliothèques partagées
programme msgfmt pour le support des langues
chemin complet vers l'interpréteur Perl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Perl.
chemin complet vers l'interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python.
chemin complet vers l'interpréteur Tcl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Tcl.
programme xml2-config utilisé pour localiser l'installation de libxml.
programme Yacc (bison -y si utilisation de Bison)
Compilation
Pour démarrer la compilation, saisissez
gmake
(Rappelez-vous d'utiliser GNU make). La compilation prendra quelques minutes, suivant de votre matériel. La dernière ligne affichée devrait être
All of PostgreSQL is successfully made. Ready to install.
Tests de régression
Si vous souhaitez tester le serveur nouvellement compileé avant de l'installer, vous pouvez exécuter les tests de régression à ce moment. Les tests de régression sont une suite de tests qui vérifient que PostgreSQL™ fonctionne sur votre machine tel que les développeurs l'espèrent. Saisissez
gmake check
(cela ne fonctionne pas en tant que root ; faites-le en tant qu'utilisateur sans droits). Le fichier src/test/regress/README et la documentation contiennentLe ??? contient des détails sur l'interprétation des résultats de ces tests. Vous pouvez les répéter autant de fois que vous le voulez en utilisant la même commande.
Installer les fichiers
Si vous mettez à jour une version existante et que vous placez les fichiers au même endroit que les anciens, assurez-vous d'avoir sauvegardé vos données et arrêté l'ancien serveur avant de continuer, comme l'explique la Section 1.4, « Mise à jour » ci-après.
Pour installer PostgreSQL™, saisissez
gmake install
Cela installera les fichiers dans les répertoires spécifiés dans l'Étape 1. Assurez-vous d'avoir les droits appropriés pour écrire dans ces répertoires. Normalement, vous avez besoin d'être superutilisateur pour cette étape. Une alternative consiste à créer les répertoires cibles à l'avance et à leur donner les droits appropriées.
Vous pouvez utiliser gmake install-strip en lieu et place de gmake install pour dépouiller l'installation des exécutables et des bibliothèques. Cela économise un peu d'espace disque. Si vous avez effectué la compilation en mode de débogage, ce dépouillage l'enlèvera, donc ce n'est à faire seulement si ce mode n'est plus nécessaire. install-strip essaie d'être raisonnable en sauvegardant de l'espace disque mais il n'a pas une connaissance parfaite de la façon de dépouiller un exécutable de tous les octets inutiles. Ainsi, si vous voulez sauvegarder le maximum d'espace disque, vous devrez faire le travail à la main.
L'installation standard fournit seulement les fichiers en-têtes nécessaires pour le développement d'applications clientes ainsi que pour le développement de programmes côté serveur comme des fonction personnelles ou des types de données écrits en C (avant PostgreSQL™ 8.0, une commande gmake install-all-headers séparée était nécessaire pour ce dernier point mais cette étape a été intégrée à l'installation standard).
Installation du client uniquement : Si vous voulez uniquement installer les applications clientes et les bibliothèques d'interface, alors vous pouvez utilisez ces commandes :
gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install
src/bin comprend quelques exécutables utilisés seulement par le serveur mais ils sont petits.
Enregistrer eventlog sur Windows : Pour enregistrer une bibliothèque eventlog sur Windows grâce au système d'exploitation, exécutez cette commande après l'installation :
regsvr32 pgsql_library_directory/pgevent.dll
Ceci crée les entrées du registre utilisées par le visualisateur d'événements.
Désinstallation : Pour désinstaller, utilisez la commande gmake uninstall. Cependant, cela ne supprimera pas les répertoires créés.
Ménage : Après l'installation, vous pouvez faire le ménage en supprimant les fichiers issus de la compilation des répertoires sources à l'aide de la commande gmake clean. Cela conservera les fichiers créés par la commande configure, ainsi vous pourrez tout recompiler ultérieurement avec gmake. Pour remettre l'arborescence source dans l'état initial, utilisez gmake distclean. Si vous voulez effectuer la compilation pour diverses plateformes à partir des mêmes sources vous devrez d'abord refaire la configuration à chaque fois (autrement, utilisez un répertoire de construction séparé pour chaque plateforme, de façon à ce que le répertoire des sources reste inchangé).
Si vous avez compilé et que vous vous êtes rendu compte que les options de configure sont fausses ou si vous changez quoique ce soit que configure prenne en compte (par exemple, la mise à jour d'applications), alors faire un gmake distclean avant de reconfigurer et recompiler est une bonne idée. Sans ça, vos changements dans la configuration ne seront pas répercutés partout où il faut.
Sur certains systèmes qui utilisent les bibliothèques partagées (ce que font de nombreux systèmes), vous avez besoin de leurs spécifier comment trouver les nouvelles bibliothèques partagées. Les systèmes sur lesquels ce n'est pas nécessaire comprennent BSD/OS, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, Tru64 UNIX (auparavant Digital UNIX) et Solaris.
La méthode pour le faire varie selon la plateforme, mais la méthode la plus répandue consiste à positionner des variables d'environnement comme LD_LIBRARY_PATH : avec les shells Bourne (sh, ksh, bash, zsh) :
LD_LIBRARY_PATH=/usr/local/pgsql/lib export LD_LIBRARY_PATH
ou en csh ou tcsh :
setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
Remplacez /usr/local/pgsql/lib par la valeur donnée à --libdir dans l'Étape 1. Vous pouvez mettre ces commandes dans un script de démarrage tel que /etc/profile ou ~/.bash_profile. Certaines informations pertinentes au sujet de mises en garde associées à cette méthode peuvent être trouvées sur http://www.visi.com/~barr/ldpath.html.
Sur certains systèmes, il peut être préférable de renseigner la variable d'environnement LD_RUN_PATH avant la compilation.
Avec Cygwin, placez le répertoire des bibliothèques dans la variable PATH ou déplacez les fichiers .dll dans le répertoire bin.
En cas de doute, référez-vous aux pages de man de votre système (peut-être ld.so ou rld). Si vous avez ultérieurement un message tel que
psql: error in loading shared libraries libpq.so.2.1: cannot open shared object file: No such file or directory
alors cette étape est vraiment nécessaire. Faites-y attention.
Si votre système d'exploitation est BSD/OS, Linux ou SunOS 4 et que vous avez les accès de superutilisateur, vous pouvez exécuter :
/sbin/ldconfig /usr/local/pgsql/lib
(ou le répertoire équivalent) après l'installation pour permettre à l'éditeur de liens de trouver les bibliothèques partagées plus rapidement. Référez-vous aux pages man portant sur ldconfig pour plus d'informations. Pour les systèmes d'exploitation FreeBSD, NetBSD et OpenBSD, la commande est :
/sbin/ldconfig -m /usr/local/pgsql/lib
Les autres systèmes d'exploitation ne sont pas connus pour avoir de commande équivalente.
Si l'installation a été réalisée dans /usr/local/pgsql ou à un autre endroit qui n'est pas dans les répertoires contenant les exécutables par défaut, vous devez ajouter /usr/local/pgsql/bin (ou le répertoire fourni à --bindir au moment de l'Étape 1) dans votre PATH. Techniquement, ce n'est pas une obligation mais cela rendra l'utilisation de PostgreSQL™ plus confortable.
Pour ce faire, ajoutez ce qui suit dans le fichier d'initialisation de votre shell, par exemple ~/.bash_profile (ou /etc/profile, si vous voulez que tous les utilisateurs l'aient) :
PATH=/usr/local/pgsql/bin:$PATH export PATH
Si vous utilisez le csh ou le tcsh, alors utilisez la commande :
set path = ( /usr/local/pgsql/bin $path )
Pour que votre système trouve la documentation man, il vous faut ajouter des lignes telles que celles qui suivent à votre fichier d'initialisation du shell, à moins que vous installiez ces pages dans un répertoire où elles sont mises normalement :
MANPATH=/usr/local/pgsql/man:$MANPATH export MANPATH
Les variables d'environnement PGHOST et PGPORT indiquent aux applications clientes l'hôte et le port du serveur de base. Elles surchargent les valeurs utilisées lors de la compilation. Si vous exécutez des applications clientes à distance, alors c'est plus pratique si tous les utilisateurs peuvent paramétrer PGHOST. Ce n'est pas une obligation, cependant, la configuration peut être communiquée via les options de lignes de commande à la plupart des programmes clients.
La suite est un résumé rapide de la façon de faire fonctionner PostgreSQL™ une fois l'installation terminée. La documentation principale contient plus d'informations.
Créer un compte utilisateur pour le serveur PostgreSQL™. C'est cet utilisateur qui fera démarrer le serveur. Pour un usage en production, vous devez créer un compte sans droits (« postgres » est habituellement utilisé). Si vous n'avez pas les accès superutilisateur ou si vous voulez juste regarder, votre propre compte utilisateur est suffisant. Mais, utiliser le compte superutilisateur pour démarrer le serveur est risqué (au point de vue sécurité) et ne fonctionnera pas.
adduser postgres
Faire l'installation de la base de données avec la commande initdb. Pour exécuter initdb, vous devez être connecté sur votre serveur avec le compte PostgreSQL™. Cela ne fonctionnera pas avec le compte superutilisateur.
root# mkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data root# su - postgres postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
L'option -D spécifie le répertoire où les données seront stockées. Vous pouvez utiliser le chemin que vous voulez, il n'a pas à être sous le répertoire de l'installation. Avant de lancer initdb, assurez-vous que le compte serveur peut écrire dans ce répertoire (ou le créer s'il n'existe pas), comme c'est montré ici.
À ce moment, si vous n'utilisez pas l'option -A de initdb, vous devez modifier le fichier pg_hba.conf pour contrôler les accès en local du serveur avant de le lancer. La valeur par défaut est de faire confiance à tous les utilisateurs locaux.
L'étape initdb précédente vous a indiqué comment démarrer le serveur de base. Maintenant, faites-le. La commande doit ressembler à :
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Cela démarrera le serveur en avant-plan. Pour le mettre en arrière plan faites quelque chose comme :
nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \
</dev/null >>server.log 2>&1 </dev/null &
Pour arrêter le serveur fonctionnant en arrière-plan, vous pouvez saisir :
kill `cat /usr/local/pgsql/data/postmaster.pid`
Créer une base de données :
createdb testdb
Ensuite, entrez
psql testdb
pour vous connecter à la base. À l'invite, vous pouvez saisir des commandes SQL et commencer l'expérimentation.
La distribution de PostgreSQL™ comprend un document compréhensible que vous devriez lire de temps en temps. Après l'installation, le document peut être lu en faisant pointer votre navigateur internet sur /usr/local/pgsql/doc/html/index.html, excepté si vous avez changé les répertoires d'installation.
Le premier chapitre de la documentation est un tutoriel qui devrait être votre première lecture si vous êtes nouveau dans le monde des bases de données SQL. Si vous êtes familier avec les concepts des bases de données, alors vous voudrez commencer avec la partie administration du serveur qui contient des informations sur la façon de mettre en place le serveur de base, les bases des utilisateurs et l'authentification.
Normalement, vous voudrez faire en sorte que le serveur de base démarre automatiquement au boot de la machine. Pour ce faire, quelques suggestions se trouvent dans la documentation.
Faire les tests de régression sur le serveur installé (en utilisant gmake installcheck). Si vous ne l'avez pas fait auparavant, vous devriez définitivement le faire maintenant. C'est aussi expliqué dans la documentation.
Par défaut, PostgreSQL™ est configuré pour fonctionner sur un matériel mimimal. Ceci lui permet de fonctionner sur pratiquement toutes les configurations matérielles. Néanmoins, la configuration par défaut n'est pas conçue pour des performances optimales. Pour disposer des meilleures performances, plusieurs paramètres serveurs doivent être ajustés, les deux plus communs étant shared_buffers et work_mem. Les autres paramètres mentionnés dans la documentation affectent aussi les performances.
Une platforme (c'est-à-dire une combinaison d'un processeur et d'un système d'exploitation) est considérée supportée par la communauté de développeur de PostgreSQL™ si le code permet le fonctionnement sur cette plateforme et que la construction et les tests de regréssion ont été récemment vérifiés sur cette plateforme. Actuellement, la plupart des tests de compatibilité de plateforme se fait automatiquement par des machines de tests dans la ferme de construction de PostgreSQL. Si vous êtes intéressés par l'utilisation de PostgreSQL™ sur une plateforme qui n'est pas représentée dans la ferme de construction, mais pour laquelle le code fonctionne ou peut fonctionner, nous vous suggérons fortement de construction une machine qui sera membre de la ferme pour que la compatibilité puisse être assurée dans la durée.
En général, PostgreSQL™ doit fonctionner sur les architectures processeur suivantes : x86, x86_64, IA64, PowerPC, PowerPC 64, S/390, S/390x, Sparc, Sparc 64, Alpha, ARM, MIPS, MIPSEL, M68K et PA-RISC. Un support du code existe pour M32R, NS32K et VAX mais ces architectures n'ont pas été testées récemment à notre connaissance. Il est souvent possible de construire PostgreSQL™ sur un type de processeur non supporté en précisant --disable-spinlocks. Cependant, les performance en souffriront.
PostgreSQL™ doit fonctionner sur les systèmes d'exploitation suivants : Linux (toutes les distributions récentes), Windows (Win2000 SP4 et ultérieure), FreeBSD, OpenBSD, NetBSD, Mac OS X, AIX, HP/UX, IRIX, Solaris, Tru64 Unix et UnixWare. D'autres systèmes style Unix peuvent aussi fonctionner mais n'ont pas été récemment testés. Dans la plupart des cas, toutes les architectures processeurs supportées par une système d'exploitation données fonctionneront. Cherchez dans le répertoire doc/ de la distribution des sources pour vérifier s'il existe une FAQ spécifique à votre système d'exploitation, tout particulièrement dans le cas d'un vieux système.
Si vous avez des problèmes d'installation sur une plateforme qui est connu comme étant supportée d'après les récents résultats de la ferme de construction, merci de rapporter cette information à <pgsql-bugs@postgresql.org>. Si vous êtes intéressé pour porter PostgreSQL™ sur une nouvelle plateforme, <pgsql-hackers@postgresql.org> est l'endroit approprié pour en discuter.