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

Version anglaise

16.4. Procédure d'installation

  1. Configuration

    La première étape de la procédure d'installation est de configurer l'arborescence système et de choisir les options intéressantes. Ce qui est fait en exécutant le script configure. Pour une installation par défaut, entrer simplement

    ./configure

    Ce script exécutera de nombreux tests afin de déterminer les valeurs de certaines variables dépendantes du système et de détecter certains aléas relatifs au système d'exploitation. Il créera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a été trouvé. configure peut aussi être exécuté à partir d'un répertoire hors de l'arborescence des sources pour conserver l'arborescence de compilation séparée. Cette procédure est aussi appelée une construction de type VPATH. Voici comment la faire :

    mkdir build_dir
    cd build_dir
    /path/to/source/tree/configure [les options vont ici]
    make
       

    La configuration par défaut compilera le serveur et les utilitaires, aussi bien que toutes les applications clientes et interfaces qui requièrent seulement un compilateur C. Tous les fichiers seront installés par défaut sous /usr/local/pgsql.

    Les processus de compilation et d'installation peuvent être personnalisés par l'utilisation d'une ou plusieurs options sur la ligne de commande après configure :

    --prefix=PREFIX

    Installe tous les fichiers dans le répertoire PREFIX au lieu du répertoire /usr/local/pgsql. Les fichiers actuels seront installés dans divers sous-répertoires ; aucun fichier ne sera directement installé sous PREFIX.

    Pour satisfaire des besoins spécifiques, les sous-répertoires peuvent être personnalisés à l'aide des options qui suivent. Toutefois, en laissant les options par défaut, l'installation est déplaçable, ce qui signifie que le répertoire peut être déplacé après installation. (Cela n'affecte pas les emplacements de man et doc.)

    Pour les installations déplaçables, on peut utiliser l'option --disable-rpath de configure. De plus, il faut indiquer au système d'exploitation comment trouver les bibliothèques partagées.

    --exec-prefix=EXEC-PREFIX

    Les fichiers qui dépendent de l'architecture peuvent être installés dans un répertoire différent, EXEC-PREFIX, de celui donné par PREFIX. Cela peut être utile pour partager les fichiers indépendant de l'architecture entre plusieurs machines. S'il est omis, 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 le but recherché.

    --bindir=REPERTOIRE

    Précise le répertoire des exécutables. Par défaut, il s'agit de EXEC-PREFIX/bin, ce qui signifie /usr/local/pgsql/bin.

    --sysconfdir=REPERTOIRE

    Précise le répertoire de divers fichiers de configuration. Par défaut, il s'agit de PREFIX/etc.

    --libdir=REPERTOIRE

    Précise le répertoire d'installation des bibliothèques et des modules chargeables dynamiquement. Par défaut, il s'agit de EXEC-PREFIX/lib.

    --includedir=REPERTOIRE

    Précise le répertoire d'installation des en-têtes C et C++. Par défaut, il s'agit de PREFIX/include.

    --datarootdir=REPERTOIRE

    Indique le répertoire racine de différents types de fichiers de données en lecture seule. Cela ne sert qu'à paramétrer des valeurs par défaut pour certaines des options suivantes. La valeur par défaut est PREFIX/share.

    --datadir=REPERTOIRE

    Indique le répertoire pour les fichiers de données en lecture seule utilisés par les programmes installés. La valeur par défaut est DATAROOTDIR. Cela n'a aucun rapport avec l'endroit où les fichiers de base de données seront placés.

    --localedir=REPERTOIRE

    Indique le répertoire pour installer les données locales, en particulier les fichiers catalogues de traductions de messages. La valeur par défaut est DATAROOTDIR/locale.

    --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 DATAROOTDIR/man.

    --docdir=RÉPERTOIRE

    Configure le répertoire racine pour installer les fichiers de documentation, sauf les pages « man ». Ceci ne positionne la valeur par défaut que pour les options suivantes. La valeur par défaut pour cette option est DATAROOTDIR/doc/postgresql.

    --htmldir=RÉPERTOIRE

    La documentation formatée en HTML pour PostgreSQL™ sera installée dans ce répertoire. La valeur par défaut est DATAROOTDIR.

    [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é aux répertoires datadir, sysconfdir et docdir, à moins que le nom du répertoire à partir de la racine contienne déjà le mot « postgres » ou « pgsql ». Par exemple, si /usr/local est choisi 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ête publiques C de l'interface cliente seront installés sous includedir et sont indépendants des noms de fichiers relatifs au reste du système. Les fichiers d'en-tête privés et les fichiers d'en-tête 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-extra-version=STRING

    Ajoute STRING au numéro de version de PostgreSQL. Cela peut être utilisé, par exemple, pour marquer des binaires compilés depuis des instantanés Git ne faisant pas encore partie d'une version officielle ou contenant des patchs particuliers avec une chaîne de texte supplémentaire telle qu'un identifiant git describe ou un numéro de version d'un paquet d'une distribution.

    --with-includes=REPERTOIRES

    REPERTOIRES est une liste de répertoires séparés par le caractère deux points (:) qui sera ajoutée à la liste de recherche des fichiers d'en-tête du compilateur. Si vous avez des paquetages optionnels (tels que Readline GNU) installés dans des répertoires non conventionnels, vous devez utiliser cette option et probablement aussi 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 le caractère deux points (:). Si des paquets sont installés dans des répertoires non conventionnels, il peut s'avérer nécessaire d'utiliser cette option (ainsi que l'option correspondante --with-includes).

    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 capacité d'afficher les messages d'un programme dans une langue autre que l'anglais. LANGUES est une liste optionnelle des codes de langue que vous voulez supporter séparés par un espace. Par exemple, --enable-nls='de fr' (l'intersection entre la liste et l'ensemble des langues traduites actuellement sera calculée automatiquement). En l'absence de liste, toutes les traductions disponibles seront installées.

    Pour utiliser cette option, une implantation de l'API Gettext est nécessaire ; voir ci-dessous.

    --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 modifié ultérieurement mais, s'il est précisé ici, 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 autre valeur que celle par défaut est l'exécution de 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 pour utiliser une version différente de Tcl, il faut indiquer le répertoire dans lequel il se trouve.

    --with-gssapi

    Permet la compilation 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ête et les bibliothèques nécessaires pour s'assurer que votre installation GSSAPI est suffisante avant de continuer.

    --with-krb-srvnam=NOM

    Le nom par défaut du service principal de Kerberos utilisé. 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-llvm

    Permet la compilation avec le support de JIT basée sur LLVM™. Ceci nécessite l'installation de la bibliothèque LLVM™. La version minimale requise de LLVM™ est actuellement la 3.9.

    llvm-config sera utilisé pour trouver les options de compilation requises. llvm-config, puis llvm-config-$major-$minor pour toutes les versions supportées, seront recherché dans PATH. Dans le cas où les bons binaires ne sont pas trouvés, il faut utiliser la variable LLVM_CONFIG afin de spécifier le chemin à llvm-config. Par exemple :

    ./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'
    

    Le support de LLVM™ nécessite un compilateur clang compatible (qui peut être spécifié, si nécessaire, en utilisant la variable d'environnement CLANG, et un compilateur C++ fonctionnel (qui peut être spécifié, si nécessaire, en utilisant la variable d'environnement CXX).

    --with-icu

    Installer PostgreSQL avec la bibliothèque ICU™ L'installation des paquets ICU4C™ et pkg-config™ sont un pré-requis. La version minimale requise de ICU4C™ est actuellement la 4.2.

    Par défaut, pkg-config™ sera utilisé pour trouver les options requises de compilation. C'est supporté par les versions 4.6 et ultérieures de ICU4C™. Pour les versions plus anciennes ou si pkg-config™ n'est pas disponible, les variables ICU_CFLAGS et ICU_LIBS peuvent être données à configure, comme dans cet exemple :

    ./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'
    

    (Si ICU4C™ est dans le chemin de recherche par défaut du compilateur, alors vous aurez besoin d'indiquer une chaîne non vide pour éviter l'utilisation de pkg- config™, par exemple ICU_CFLAGS=' '.)

    --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-bsd-auth

    Compile le support de l'authentification BSD (l'environnement d'authentification BSD est uniquement disponible sur OpenBSD actuellement.)

    --with-ldap

    Demande l'ajout du support de LDAP pour l'authentification et la recherche des paramètres de connexion (voir Section 34.17, « Recherche LDAP des paramètres de connexion » et Section 20.10, « Authentification LDAP »). Sur Unix, cela requiert l'installation du paquet OpenLDAP™. Sur Windows, la bibliothèque WinLDAP™ est utilisée par défaut. 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.

    --with-systemd

    Compile le support des notifications du service systemd . Ceci améliore l'intégration si le binaire du serveur est lancé par systemd mais n'a pas d'impact dans le cas contraire (voir Section 18.3, « Lancer le serveur de bases de données » pour plus d'informations). libsystemd et les fichiers en-têtes associés doivent être installés pour pouvoir utiliser cette option.

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

    --with-uuid=LIBRARY

    Compile le module uuid-ossp (qui fournit les fonctions pour générer les UUID), en utilisant la bibliothèque UUID spécifiée. LIBRARY doit correspondre à une de ces valeurs :

    • bsd pour utiliser les fonctions UUID trouvées dans FreeBSD, NetBSD et quelques autres systèmes dérivés de BSD

    • e2fs pour utiliser la bibliothèque UUID créée par le projet e2fsprogs ; cette bibliothèque est présente sur la plupart des systèmes Linux et sur macOS, et peut être obtenu sur d'autres plateformes également

    • ossp pour utiliser la bibliothèque OSSP UUID

    --with-ossp-uuid

    Équivalent obsolète de --with-uuid=ossp.

    --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 le module xml2. Le module contrib/xml2 se base sur cette bibliothèque pour réaliser les transformations XSL du XML.

    --disable-float4-byval

    Désactive le passage « par valeur » des valeurs float4, entraînant leur passage « par référence » à la place. Cette option a un coût en performance, mais peut être nécessaire pour maintenir la compatibilité avec des anciennes fonctions créées par l'utilisateur qui sont écrites en C et utilisent la convention d'appel « version 0 ». Une meilleure solution à long terme est de mettre à jour toutes ces fonctions pour utiliser la convention d'appel « version 1 ».

    --disable-float8-byval

    Désactive le passage « par valeur » des valeurs float8, entraînant leur passage « par référence » à la place. Cette option a un coût en performance, mais peut être nécessaire pour maintenir la compatibilité avec des anciennes fonctions créées par l'utilisateur qui sont écrites en C et utilisent la convention d'appel « version 0 ». Une meilleure solution à long terme est de mettre à jour toutes ces fonctions pour utiliser la convention d'appel « version 1 ». Notez que cette option n'affecte pas que float8, mais aussi int8 et quelques types apparentés comme timestamp. Sur les plateformes 32 bits, --disable-float8-byval est la valeur par défaut, et il n'est pas permis de sélectionner --enable-float8-byval.

    --with-segsize=TAILLESEG

    Indique la taille d'un segment, en gigaoctets. La valeur par défaut est de 1 gigaoctet, valeur considérée comme sûre pour toutes les plateformes prises en charge. Les grandes tables sont divisées en plusieurs fichiers du système d'exploitation, chacun de taille égale à la taille de segment. Cela évite les problèmes avec les limites de tailles de fichiers qui existent sur de nombreuses plateformes. Si votre système d'exploitation supporte les fichiers de grande taille (« largefile »), ce qui est le cas de la plupart d'entre eux de nos jours, vous pouvez utiliser une plus grande taille de segment. Cela peut être utile pour réduire le nombre de descripteurs de fichiers qui peuvent être utilisés lors de travail sur des très grandes tables. Attention à ne pas sélectionner une valeur plus grande que ce qui est supporté par votre plateforme et le(s) système(s) de fichiers que vous prévoyez d'utiliser. D'autres outils que vous pourriez vouloir utiliser, tels que tar, pourraient aussi limiter la taille maximum utilisable pour un fichier. Il est recommandé, même si pas vraiment nécessaire, que cette valeur soit une puissance de 2. Notez que changer cette valeur impose de faire un initdb.

    --with-blocksize=TAILLEBLOC

    Indique la taille d'un bloc, en kilooctets. C'est l'unité de stockage et d'entrée/sortie dans les tables. La valeur par défaut, 8 kilooctets, est appropriée pour la plupart des cas ; mais d'autres valeurs peuvent être utilisées dans des cas particuliers. Cette valeur doit être une puissance de 2 entre 1 et 32 (kilooctets). Notez que changer cette valeur impose de faire un initdb.

    --with-wal-blocksize=TAILLEBLOC

    Indique la taille d'un bloc WAL, en kilooctets. C'est l'unité de stockage et d'entrée/sortie dans le journal des transactions. La valeur par défaut, 8 kilooctets, est appropriée pour la plupart des cas ; mais d'autres valeurs peuvent être utilises dans des cas particuliers. La valeur doit être une puissance de 2 comprise entre 1 et 64 (kilooctets).

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

    --disable-strong-random

    Autorise le succès de la construction y compris lorsque PostgreSQL™ n'a pas le support pour les nombres aléatoires forts sur la plateforme. Une source de nombres aléatoires est nécessaire pour certains protocoles d'authentification, de même que certaines procédures du module pgcrypto. Le paramètre --disable-strong-random désactive toutes les fonctionnalités qui nécessitent des nombres aléatoires forts pour la cryptographie et y substitue un générateur fragile de nombres pseudo aléatoires pour générer les valeurs pour l'authentification salée et les clés d'annulation de requêtes. Cela rend l'authentification moins sécurisée.

    --disable-thread-safety

    Désactive la sécurité des threads pour les bibliothèques clients. Ceci empêche les threads concurrents dans les programmes libpq et ECPG de contrôler en toute sécurité leurs pointeurs de connexion privés.

    --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 IANA 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 incluse 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 construits 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-coverage

    Si vous utilisez GCC, les programmes et bibliothèques sont compilés avec de l'instrumentation de test de couverture de code. Quand ils sont exécutés, ils génèrent des fichiers dans le répertoire de compilation avec des métriques de couverture de code. Voir Section 33.5, « Examen de la couverture du test » pour davantage d'informations. Cette option ne doit être utilisée qu'avec GCC et uniquement en phase de développement.

    --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 uniquement 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 PostgreSQL™ avec le support de l'outil de trace dynamique, DTrace. Voir Section 28.5, « Traces dynamiques » pour plus d'informations.

    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. Sur Solaris, 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' ...
           
    --enable-tap-tests

    Active les tests utilisant les outils TAP de Perl. Cela nécessite une installation de Perl et de son module IPC::Run. Voir Section 33.4, « TAP Tests » pour plus d'informations.

    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.

    Les variables d'environnement peuvent être indiquées 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 cette façon :

    BISON

    programme Bison

    CC

    compilateur C

    CFLAGS

    options à passer au compilateur C

    CLANG

    chemin vers le programme clang utilisé pour l'optimisation inline du code source lors de la compilation avec --with-llvm

    CPP

    préprocesseur C

    CPPFLAGS

    options à passer au préprocesseur C

    CXX

    C++ compiler

    CXXFLAGS

    options to pass to the C++ compiler

    DTRACE

    emplacement du programme dtrace

    DTRACEFLAGS

    options à passer au programme dtrace

    FLEX

    programme Flex

    LDFLAGS

    options à utiliser lors de l'édition des liens des exécutables et des bibliothèques partagées

    LDFLAGS_EX

    options supplémentaires valables uniquement lors de l'édition des liens des exécutables

    LDFLAGS_SL

    options supplémentaires valables uniquement lors de l'édition des liens des bibliothèques partagées

    LLVM_CONFIG

    llvm-config program used to locate the LLVM™ installation.

    MSGFMT

    programme msgfmt pour le support des langues

    PERL

    programme interpréteur Perl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Perl. La valeur par défaut est perl.

    PYTHON

    chemin complet vers l'interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python. De plus, si Python 2 ou 3 est spécifié ici (ou implicitement choisi), il détermine la variante de PL/Python qui devient disponible. Voir Section 33.4, « TAP Tests » pour plus d'informations.

    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.

    Les variables d'environnement peuvent être indiquées 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 cette façon :

    BISON

    programme Bison

    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

    FLEX

    programme Flex

    LDFLAGS

    options à utiliser lors de l'édition des liens des exécutables et des bibliothèques partagées

    LDFLAGS_EX

    options supplémentaires valables uniquement lors de l'édition des liens des exécutables

    LDFLAGS_SL

    options supplémentaires valables uniquement lors de l'édition 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

    programme interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python. De plus, si Python 2 ou 3 est spécifié ici (ou implicitement choisi), il détermine la variante de PL/Python qui devient disponible. Voir Section 46.1, « Python 2 et Python 3 » pour plus d'informations. Si cette variable n'est pas configurée, les suivantes sont testées dans cet ordre : python python3 python2.

    TCLSH

    programme interpréteur Tcl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Tcl, et il sera substitué dans des scripts Tcl.

    XML2_CONFIG

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

    Il est parfois utile d'ajouter des options de compilation à l'ensemble choisi par configure après coup. Un exemple parlant concerne l'option -Werror de gcc qui ne peut pas être incluse dans la variable CFLAGS passée à configure, car il cassera un grand nombre de tests internes de configure. Pour ajouter de telles options, incluez- les dans la variable d'environnement COPT lors de l'exécution de gmake. Le contenu de COPT est ajouté aux variables CFLAGS et LDFLAGS configurées par configure. Par exemple, vous pouvez faire :

    gmake COPT='-Werror'
    

    ou

    export COPT='-Werror'
    gmake
    
    [Note]

    Note

    Lors de l'écriture de code à l'intérieur du serveur, il est recommandé d'utiliser les options --enable-cassert (qui active un grand nombre de vérifications d'erreur à l'exécution) et --enable-debug (qui améliore l'utilité des outils de débogage) de configure.

    Si vous utilisez GCC, il est préférable de construire avec un niveau d'optimisation d'au moins -O1 parce que désactiver toute optimisation (-O0) désactive aussi certains messages importants du compilateur (comme l'utilisation de variables non initialisées). Néanmoins, les niveaux d'optimisations peuvent compliquer le débuggage parce que faire du pas-à-pas sur le code compilé ne correspondra pas forcément aux lignes de code une-à-une. Si vous avez du mal à débugger du code optimisé, recompilez les fichiers intéressants avec -O0. Une façon simple de le faire est de passer une option à make: make PROFILE=-O0 file.o.

    Les variables d'environnement COPT et PROFILE sont gérées de façon identique par les fichiers makefile de PostgreSQL™. Laquelle utiliser est une affaire de préférence, mais un usage commun parmi les développeurs est d'utiliser PROFILE pour les ajustements inhabituels alors que COPT servirait aux variables à configurer à chaque fois.

  2. Compilation

    Pour démarrer la compilation, saisissez soit

    make
    make all

    (Rappelez-vous d'utiliser GNU make). La compilation prendra quelques minutes, selon votre matériel. La dernière ligne affichée devrait être

                      All of PostgreSQL successfully made. Ready to install.

    Si vous voulez lancer la construction à partir d'un autre fichier makefile, vous devez configurer MAKELEVEL ou l'initialiser à zéro, par exemple ainsi :

    build-postgresql:
            $(MAKE) -C postgresql MAKELEVEL=0 all
    

    Ne pas le faire amène des messages d'erreur étranges, typiquement sur des fichiers d'en-tête manquants.

    Si vous voulez construire tout ce qui peut être construit, ceci incluant la documentation (HTML et pages man) et les modules supplémentaires (contrib), saisissez à la place :

    make world
       

    La dernière ligne affichée doit être :

    PostgreSQL, contrib, and documentation successfully made. Ready to install.
       
  3. Tests de régression

    Si vous souhaitez tester le serveur nouvellement compilé 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

    make check

    (cela ne fonctionne pas en tant que root ; faites-le en tant qu'utilisateur sans droits). Le Chapitre 33, 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, assurez-vous d'avoir bien lu Section 18.6, « Mise à jour d'une instance PostgreSQL™ » qui donne les instructions sur la mise à jour d'un cluster.

    Pour installer PostgreSQL™, saisissez

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

    Pour installer la documentation (HTML et pages man), saisissez :

    make install-docs
       

    Si vous construisez tout, saisissez ceci à la place :

    make install-world
       

    Cela installe aussi la documentation.

    Vous pouvez utiliser make install-strip en lieu et place de make 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 fonctions personnelles ou des types de données écrits en C (avant PostgreSQL™ 8.0, une commande make 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 :

    make -C src/bin install
    make -C src/include install
    make -C src/interfaces install
    make -C doc install

    src/bin comprend quelques exécutables utilisés seulement par le serveur mais ils sont petits.

Désinstallation :  Pour désinstaller, utilisez la commande make uninstall. Cependant, cela ne supprimera pas les répertoires créés.

Nettoyage :  Après l'installation, vous pouvez libérer de l'espace en supprimant les fichiers issus de la compilation des répertoires sources à l'aide de la commande make clean. Cela conservera les fichiers créés par la commande configure, ainsi vous pourrez tout recompiler ultérieurement avec make. Pour remettre l'arborescence source dans l'état initial, utilisez make 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 quoi que ce soit que configure prenne en compte (par exemple, la mise à jour d'applications), alors faire un make 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.