PostgreSQLLa base de données la plus sophistiquée au monde.

15.5. Procédure d'installation

  1. 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 :

    --prefix=PREFIX

    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.

    --exec-prefix=EXEC-PREFIX

    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.

    --bindir=REPERTOIRE

    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.

    --datadir=REPERTOIRE

    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.

    --sysconfdir=REPERTOIRE

    Le répertoire contenant divers fichiers de configuration. Par défaut, il s'agit de PREFIX/etc.

    --libdir=REPERTOIRE

    L'endroit où installer les bibliothèques et les modules chargeables dynamiquement. Par défaut, il s'agit de EXEC-PREFIX/lib.

    --includedir=REPERTOIRE

    Le répertoire où sont installées les en-têtes C et C++. Par défaut, il s'agit de PREFIX/include.

    --mandir=REPERTOIRE

    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.

    --with-docdir=REPERTOIRE, --without-docdir

    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.

    [Note]

    Note

    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 »« 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.

    --with-includes=REPERTOIRES

    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.

    --with-libraries=REPERTOIRES

    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.

    --enable-nls[=LANGUES]

    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.

    --with-pgport=NUMERO

    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.

    --with-perl

    Permet l'utilisation du langage de procédures PL/Perl côté serveur.

    --with-python

    Permet la compilation du langage de procédures PL/Python.

    --with-tcl

    Permet la compilation du langage de procédures PL/Tcl.

    --with-tclconfig=REPERTOIRE

    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.

    --with-gssapi

    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.

    --with-krb5

    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

    --with-krb-srvnam=NOM

    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.

    --with-openssl

    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.

    --with-pam

    Compile le support PAM (Modules d'Authentification Pluggable).

    --with-ldap

    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 libpqSection 30.15, « Recherches LDAP des paramètres de connexion » et Section 21.2.7, « Authentification LDAP »). 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.

    --without-readline

    É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é.

    --with-libedit-preferred

    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é.

    --with-bonjour

    Compile le support de Bonjour. Ceci requiert le support de Bonjour dans votre système d'exploitation. Recommandé sur Mac OS X.

    --with-ossp-uuid

    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.

    --with-libxml

    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.

    --with-libxslt

    Utilise libxslt pour construire contrib/xml2. Le module contrib/xml2 se base sur cette bibliothèque pour réaliser les transformations XSL du XML.

    --enable-integer-datetimes

    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 heureSection 8.5, « Types date/heure » pour plus d'informations).

    --disable-spinlocks

    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™.

    --enable-thread-safety

    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.

    --with-system-tzdata=RÉPERTOIRE

    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.

    --without-zlib

    É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.

    --enable-debug

    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.

    --enable-profiling

    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.

    --enable-cassert

    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.

    --enable-depend

    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.

    --enable-dtrace

    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 :

    CC

    compilateur C

    CFLAGS

    options à passer au compilateur C

    CPP

    préprocesseur C

    CPPFLAGS

    options à passer au préprocesseur C

    DTRACE

    emplacement du programme dtrace

    DTRACEFLAGS

    options à passer au programme dtrace

    LDFLAGS

    options à passer à l'éditeur de liens

    LDFLAGS_SL

    options de l'éditeur de liens pour la création des liens des bibliothèques partagées

    MSGFMT

    programme msgfmt pour le support des langues

    PERL

    chemin complet vers l'interpréteur Perl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Perl.

    PYTHON

    chemin complet vers l'interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python.

    TCLSH

    chemin complet vers l'interpréteur Tcl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Tcl.

    XML2_CONFIG

    programme xml2-config utilisé pour localiser l'installation de libxml.

    YACC

    programme Yacc (bison -y si utilisation de Bison)

  2. 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.
    
  3. 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 Chapitre 29, Tests de régression 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.

  4. Installer les fichiers

    [Note]

    Note

    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 15.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.