./configure make su make install adduser postgres mkdir -p /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/pg_ctl -D /usr/local/pgsql/data -l logfile start /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test
La version longue correspond au reste de cette section.
Configuration
    La première étape de la procédure d'installation est de configurer
    l'arborescence système et de choisir les options qui vous intéressent.
    Cela se fait en exécutant le script configure. Pour une
    installation par défaut, entrer simplement
./configureCe script exécutera de nombreux tests afin de déterminer les valeurs de certaines variables dépendantes du système, et de détecter certaines spécificités de votre système d'exploitation. Il créera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a été trouvé.
    Pour garder une arborescence de compilation séparée de celle des sources,
    configure peut être exécuté à
    partir d'un répertoire hors de l'arborescence des sources,
    où la compilation s'effectuera.
    Cette procédure est aussi appelée une compilation de type
    VPATH.
    Voici comment faire :
mkdir build_dircd build_dir/path/to/source/tree/configure [les options vont ici]make
   La configuration par défaut compilera le serveur et les outils,
   ainsi que toutes les applications clientes et les interfaces ne nécessitant
   qu'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
   en fournissant une ou plusieurs options de ligne de commande à
   configure.
   Généralement, vous allez personnaliser l'endroit de l'installation,
   ou la liste des fonctionnalités optionnelles à compiler.
   configure a beaucoup d'options, décrites dans
   Section 17.3.3.
  
   configure tient aussi compte de certaines
   variables d'environnement, comme décrit dans Section 17.3.4.
   Elle offre d'autres moyens de personnaliser la configuration.
  
Compilation
Pour démarrer la compilation, entrez l'un de ces ordres :
makemake all
(Rappelez-vous qu'il faut GNU make.) La durée de la compilation sera de quelques minutes, et dépend de votre matériel.
   Si vous voulez compiler tout ce qui peut l'être,
   dont la documentation (HTML et pages de manuel)
   et les modules optionnels (contrib),
   entrez plutôt :
   
make world
   La dernière ligne affichée doit être :
PostgreSQL, contrib, and documentation successfully made. Ready to install.
   Si vous voulez compiler tout ce qui peut être compilé, en incluant les
   modules supplémentaires (contrib), mais sans la
   documentation, saisissez à la place :
make world-bin
   
   Si vous voulez lancer la compilation depuis un autre makefile
   plutôt que manuellement, vous devez désactiver la variable
   MAKELEVEL ou la mettre à zéro, par exemple ainsi :
   
build-postgresql:
        $(MAKE) -C postgresql MAKELEVEL=0 all
   L'oublier peut mener à d'étranges messages d'erreur, typiquement sur des fichiers d'en-tête manquants.
Tests de régression
Si, avant de l'installer, vous voulez tester ce serveur nouvellement compilé, vous devez lancer les tests de régression maintenant. Il s'agit d'une suite de tests pour vérifier que PostgreSQL fonctionne sur votre machine de la manière prévue par ses développeurs. Entrez :
make check
   (Cela ne fonctionnera pas en tant que root ; faites-le en tant qu'utilisateur non privilégié.) Voir Chapitre 31 pour des informations détaillées sur l'interprétation des résultats des tests. Vous pouvez répéter ces tests n'importe quand par la suite en entrant la même commande.
Installer les fichiers
Si vous mettez à jour un système existant, assurez-vous de lire Section 18.6, qui contient des instructions sur la mise à jour d'une instance.
Pour installer PostgreSQL, entrez :
make install
   Cela installera les fichiers dans les répertoires spécifiés dans Étape 1. Assurez-vous que vous avez les droits nécessaires pour y écrire. Normalement, vous devez faire cela en tant que root. Une alternative est de créer les répertoires cibles par avance, et de vous arranger pour obtenir les permissions adéquates.
Si vous voulez tout construire, sauf la documentation, saisissez à la place :
make install-world-bin
Pour installer la documentation (HTML et pages de manuel), entrez :
make install-docs
   
   Si vous avez entré make world plus haut,
   entrez plutôt :
   
make install-world
   Cela va installer aussi la documentation.
   Vous pouvez aussi utiliser make install-strip
   au lieu de make install pour débarrasser
   les fichiers exécutables et les bibliothèques de leurs
   informations de débogage lors de l'installation.
   Cela économisera un peu d'espace disque.
   Dans une compilation avec le support du débogage, cette purge
   va supprimer ce support ; ce n'est donc à faire que s'il n'y a
   plus besoin de débogage.
   install-strip réussit assez bien à économiser de
   l'espace, mais ne sait pas toujours effacer
   le moindre octet inutile d'un exécutable ;
   pour récupérer tout l'espace disque possible, vous devrez donc
   terminer manuellement.
  
L'installation standard fournit tous les fichiers d'en-tête nécessaires au développement d'applications clientes, comme pour celui côté serveur, par exemple pour des fonctions spécifiques ou des types de données codés en C.
Installation cliente : Si vous voulez installer uniquement les applications clientes et les bibliothèques d'interface, vous pouvez utiliser ces commandes :
make -C src/bin installmake -C src/include installmake -C src/interfaces installmake -C doc install
    src/bin contient quelques binaires
    utilisables uniquement sur le serveur, mais ils sont petits.
   
Désinstallation : 
  Pour annuler l'installation, utilisez la commande
  make uninstall.
  Cependant, cela ne supprimera pas tous les répertoires qui ont été créés.
 
Nettoyage : 
  Après l'installation, vous pouvez libérer de l'espace disque en supprimant
  les fichiers compilés de l'arborescence des sources avec la commande
  make clean.
  Cela préservera les fichiers créés par configure,
  pour que vous puissiez tout recompiler plus tard avec make.
  Pour réinitialiser l'arbre des sources dans l'état où il est distribué,
  utilisez make distclean.
  Si vous voulez compiler pour plusieurs plateformes au sein de la même
  arborescence, vous devez le lancer et reconfigurer pour chaque
  plateforme.
  (Une alternative est d'utiliser une arborescence pour chaque plateforme,
  pour qu'elles ne soient pas modifiées.)
 
 Si, après compilation, vous découvrez que vos options à configure
 étaient fausses, ou si vous changez quelque chose que configure
 a pris en compte (par exemple, par une mise à jour logicielle),
 il est conseillé de faire make distclean avant de reconfigurer
 et recompiler. Sans cela, vos choix de configuration pourraient ne pas se
 propager à tous les endroits nécessaires.
configure #
  Les paramètres en ligne de commande à configure
  sont expliqués ci-dessous.
  Cette liste n'est pas exhaustive (utilisez ./configure --help
  pour en avoir une qui le soit). Les options non évoquées ici sont
  destinées à des utilisations avancées, comme la compilation croisée,
  et figurent dans la documentation standard d'Autoconf.
 
   Ces options contrôlent où make install va poser
   les fichiers.
   L'option --prefix est suffisante dans la plupart des cas.
   Pour des besoins spécifiques, vous pouvez personnaliser les sous-répertoires
   d'installation avec d'autres options décrites dans cette section.
   Attention : changer les emplacements relatifs des différents sous-répertoires
   peut rendre l'installation non déplaçable,  
   c'est-à-dire que vous ne pourrez
   plus la déplacer par la suite.
   (Les emplacements pour man et doc
   ne sont pas concernés par cette restriction.)
   Pour obtenir des installations déplaçables, vous pouvez utiliser
   l'option --disable-rpath décrite plus bas.
  
--prefix=PREFIX #
      Installe tous les fichiers dans le répertoire PREFIX
      au lieu du répertoire /usr/local/pgsql.
      Les fichiers eux-mêmes seront installés dans divers
      sous-répertoires ; aucun fichier ne sera directement installé
      sous PREFIX.
     
--exec-prefix=EXEC-PREFIX #
      Les fichiers qui dépendent de l'architecture peuvent être installés dans
      un répertoire avec un préfixe différent, EXEC-PREFIX,
      différent de celui donné par PREFIX.
      Cela peut être utile pour partager entre plusieurs machines
      les fichiers indépendants de l'architecture.
      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 #
      Indique le répertoire des exécutables. Par défaut, il s'agit de
      EXEC-PREFIX/bin/usr/local/pgsql/bin.
     
--sysconfdir=REPERTOIRE #
      Précise le répertoire de divers fichiers de configuration,
      par défaut 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 fichiers d'en-tête 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
--localedir=REPERTOIRE #
      Indique le répertoire pour installer les données de localisation, en
      particulier les fichiers des catalogues de traduction des messages. La
      valeur par défaut est
      DATAROOTDIR/locale
--mandir=REPERTOIRE #
      Les pages de manuel fournies avec PostgreSQL seront
      installées sous ce répertoire, dans leur sous-répertoire
      man respectif.
      Par défaut, il s'agit de xDATAROOTDIR/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 de PostgreSQL, formatée en HTML,
      sera installée dans ce répertoire. La valeur par défaut est
      DATAROOTDIR
    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 l'espace de noms du 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 ne 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 ce sera dans
    /opt/postgres/doc. Les fichiers d'en-tête
    C publics pour les interfaces clientes sont installés sous
    includedir, et sont indépendants de l'espace
    de noms du système. Les fichiers d'en-tête internes et
    ceux 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, si nécessaire, un répertoire privé sera aussi créé sous
    libdir, pour les modules chargeables dynamiquement.
   
Les options décrites dans cette section permettent d'ajouter diverses fonctionnalités de PostgreSQL qui ne sont pas compilées par défaut ; pour la plupart à cause du besoin d'autres logiciels, comme décrit dans Section 17.1.
--enable-nls[=LANGUES] #
      Active le support des langues natives
      (NLS), c'est-à-dire 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 une 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 implémentation de l'API Gettext est nécessaire.
--with-perl #Permet la compilation du langage côté serveur PL/Perl
--with-python #Permet la compilation du langage côté serveur PL/Python.
--with-tcl #Permet la compilation du langage côté serveur PL/Tcl.
--with-tclconfig=REPERTOIRE #
      Tcl installe le fichier tclConfig.sh, qui contient
      des informations de configuration nécessaires pour compiler le
      module d'interfaçage avec Tcl.
      Ce fichier est normalement trouvé automatiquement à un emplacement connu,
      mais pour utiliser une version différente de Tcl, il faut indiquer le
      répertoire où chercher tclConfig.sh.
     
--with-llvm #Compile avec le support de JIT, basé sur LLVM (voir Chapitre 30). Ceci nécessite l'installation de la bibliothèque LLVM. Sa version minimale requise est actuellement la 10.
      llvm-config
      sera utilisé pour trouver les options de compilation nécessaires.
      llvm-config sera cherché dans votre
      PATH. Au cas où le bon programme n'est pas trouvé, il
      faut utiliser la variable LLVM_CONFIG pour spécifier le
      chemin du bon 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 (à spécifier, si nécessaire,
      avec la variable d'environnement CLANG),
      et un compilateur C++ fonctionnel (à spécifier, si nécessaire,
      avec la variable d'environnement CXX).
     
--with-lz4 #Compile avec le support de la compression LZ4.
--with-zstd #Compile avec le support de la compression Zstandard.
--with-ssl=LIBRARY #
      Compile avec le support pour les connexions SSL
      (avec chiffrement). Le seul LIBRARY supporté
      est openssl. Ceci nécessite que le paquet
      OpenSSL soit installé.
      configure vérifiera les fichiers d'en-tête et les
      bibliothèques pour s'assurer que votre installation
      d'OpenSSL est suffisante avant de
      continuer.
     
--with-openssl #
      Équivalent obsolète de --with-ssl=openssl.
     
--with-gssapi #
      Compile avec le support de l'authentification GSSAPI.
      MIT Kerberos doit être installé pour GSSAPI.
      Sur beaucoup d'environnements, le système GSSAPI
      (une partie de l'installation MIT Kerberos)
      n'est pas installé dans un endroit recherché par défaut
      (par exemple /usr/include ou
      /usr/lib) ; vous devez donc
      ajouter aussi les options
      --with-includes et --with-libraries.
      configure vérifiera les fichiers d'en-tête
      et les bibliothèques pour s'assurer que votre
      installation de GSSAPI est suffisante avant de continuer.
     
--with-ldap #
      Compile avec le support de
      LDAP
      pour l'authentification et la recherche des paramètres de connexion
      (voir Section 32.18 et
      Section 20.10 pour plus d'informations).
      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 nécessaires pour s'assurer que votre installation
      d'OpenLDAP est suffisante avant de continuer.
     
--with-pam #Compile avec le support de PAM (Pluggable Authentication Modules).
--with-bsd-auth #Compile avec le support de l'authentification BSD. (Le framework BSD Authentication n'est actuellement disponible que sur OpenBSD.)
--with-systemd #Compile avec le support du système de notifications systemd. Ceci améliore l'intégration si le serveur est démarré par systemd, mais n'a pas d'impact sinon ; voir Section 18.3 pour plus d'informations libsystemd et les fichiers d'en-tête associés doivent être installés pour utiliser cette option.
--with-bonjour #Compile avec le support du service de découverte automatique Bonjour. Cela nécessite le support de Bonjour dans votre système d'exploitation. Recommandé sur macOS.
--with-uuid=LIBRARY #
      Compile le module uuid-ossp (qui fournit des
      fonctions pour générer des 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 et d'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 obtenue 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 #Compile avec libxml2, activant ainsi le support de SQL/XML. Une version 2.6.23 ou ultérieure de libxml2 est requise pour cette fonctionnalité.
      Pour détecter les options requises pour le compilateur et l'éditeur de
      liens, PostgreSQL va demander à pkg-config, s'il est
      installé et s'il connaît libxml2. Sinon, le programme
      xml2-config, qui est installé par libxml2, sera
      utilisé s'il est trouvé. L'utilisation de pkg-config
      est préférée, parce qu'elle gère mieux les installations
      multiarchitectures.
     
      Pour utiliser une installation libxml2 située dans un emplacement
      inhabituel, vous pouvez configurer les variables d'environnement
      relatives à pkg-config (voir sa documentation), ou
      configurer la variable d'environnement XML2_CONFIG pour
      qu'elle pointe sur le programme xml2-config
      appartenant à l'installation libxml2, ou configurer les variables
      XML2_CFLAGS et XML2_LIBS. (Si
      pkg-config est installé, alors, pour surcharger son
      idée de l'emplacement de libxml2, vous devez renseigner soit
      XML2_CONFIG, soit XML2_CFLAGS et
      XML2_LIBS, avec des chaînes non vides.)
     
--with-libxslt #
      Compile avec libxslt, activant le module
      xml2 pour opérer des transformations XSL sur du XML.
      --with-libxml doit être spécifié aussi.
     
--with-selinux #Compile avec SElinux, activant l'extension sepgsql.
Les options décrites dans cette section permettent de désactiver certaines fonctionnalités de PostgreSQL compilées par défaut, mais que vous pouvez désactiver si ne sont pas disponibles un logiciel ou des fonctionnalités système nécessaires. L'utilisation de ces options n'est pas recommandée si ce n'est pas vraiment nécessaire.
--without-icu #Compile sans support des bibliothèques ICU, désactivant l'utilisation de la fonctionnalité des collations ICU (voir Section 23.2).
--without-readline #Empêche l'utilisation de la bibliothèque Readline (et libedit par la même occasion). Cette option désactive l'édition de la ligne de commande et l'historique dans psql.
--with-libedit-preferred #Favorise l'utilisation de la bibliothèque libedit (licence BSD). Cette option n'est importante que si vous avez les deux librairies installées ; le défaut dans ce cas est d'utiliser Readline.
--without-zlib #Empêche l'utilisation de la bibliothèque Zlib. Cela désactive le support des archives compressées dans pg_dump et pg_restore.
--disable-spinlocks #Autorise le succès de la compilation même si PostgreSQL n'a pas le support des spinlocks pour le CPU de la plateforme. Ce manque de support entraînera des performances très faibles ; du coup, cette option ne devra être utilisée que si la compilation échoue et vous informe du manque de support des spinlocks sur votre plateforme. Si cette option est nécessaire pour y compiler PostgreSQL, merci de rapporter le problème à ses développeurs.
--disable-atomics #Désactive l'utilisation des opérations atomiques sur le CPU. Cette option ne fait rien sur les plateformes qui n'ont pas ces opérations. Sur celles qui l'ont, cela entraînera de mauvaises performances. Cette option n'est utile que pour le débogage ou pour des comparatifs de performance.
--with-includes=RÉPERTOIRES #
      RÉPERTOIRES est une liste de répertoires,
      séparés par le caractère deux points (:), qui seront ajoutés à la liste de ceux
      où le compilateur recherche des fichiers d'en-tête.
      Si vous avez des paquets optionnels (comme
      GNU Readline) installés dans un
      emplacement non conventionnel, vous devez utiliser cette option,
      et probablement aussi l'option correspondante
      --with-libraries.
     
      Exemple : --with-includes=/opt/gnu/include:/usr/sup/include.
     
--with-libraries=RÉPERTOIRES #
      RÉPERTOIRES est une liste de répertoires,
      séparés par le caractère deux points (:),
      où chercher des bibliothèques de fonctions.
      Si vous avez des paquets installés dans des
      emplacements non conventionnels, vous devez utiliser cette option
      (et probablement aussi l'option correspondante
      --with-includess).
     
      Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib.
     
--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 il semble
      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
      courant 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 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 est surtout destinée aux distributeurs de paquets binaires, qui connaissent bien leur système d'exploitation. Le principal avantage de cette option est que le paquet de PostgreSQL n'aura pas besoin de mise à jour à chaque changement des règles des fuseaux horaires. 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.
--with-extra-version=CHAÎNE #
      Ajoute CHAÎNE au numéro de version de PostgreSQL.
      Par exemple, vous pouvez utiliser cela pour marquer des binaires compilés
      depuis des snapshots Git, ou contenant des patchs, avec une chaîne
      supplémentaire, comme un identifiant git describe
      ou un numéro de version de distribution du paquet.
     
--disable-rpath #
      N'indique pas aux exécutables de PostgreSQL
      qu'ils doivent chercher les bibliothèques partagées dans le
      répertoire des bibliothèques de l'installation
      (voir --libdir).
      Sur la plupart des plateformes, cette indication utilise un
      chemin absolu vers le répertoire des bibliothèques,
      et sera inutile si vous déplacez l'installation plus tard.
      Cependant, vous devrez alors fournir aux exécutables
      un autre moyen pour trouver les bibliothèques partagées.
      Typiquement, cela implique de configurer l'éditeur de liens
      du système d'exploitation pour les rechercher ;
      voir Section 17.5.1 pour plus de détails.
     
   Il est assez courant, particulièrement pour les compilations de test,
   de modifier le numéro de port avec l'option --with-pgport.
   Les autres options de cette section ne sont recommandées que pour
   les utilisateurs avancés.
  
--with-pgport=PORT #
      Positionne PORT comme numéro de port
      pour les serveurs et les clients. Le défaut est 5432.
      Le port peut toujours être changé plus tard ; mais, si vous le
      spécifiez ici, serveur et clients auront le même défaut dès la
      compilation, ce qui peut être très pratique.
      D'habitude, la seule bonne raison de sélectionner une autre valeur
      que le défaut est si vous avez l'intention de faire
      tourner plusieurs serveurs PostgreSQL
      sur la même machine.
     
--with-krb-srvnam=NOM #
      Le nom par défaut du service principal Kerberos utilisé par GSSAPI.
      postgres est le défaut.
      D'habitude, il n'y a aucune raison de changer cela, à moins que
      vous ne compiliez pour un environnement Windows  auquel cas
      ce doit être, en majuscules, POSTGRES.
     
--with-segsize=SEGSIZE #
      Définit la taille d'un segment (segment size),
      en gigaoctets.
      Au niveau du système d'exploitation, les grandes tables sont divisées
      en plusieurs fichiers, chacun d'une taille égale à la taille d'un segment.
      Cela évite des problèmes avec les limites de taille de fichiers
      qui existent sur beaucoup de plateformes.
      La taille par défaut, 1 gigaoctet, est une valeur
      sûre pour toutes les plateformes supportées.
      Si votre système d'exploitation supporte les fichiers de
      grande taille (« largefile »), et la plupart le font, de nos jours,
      vous pouvez utiliser une plus grande taille de segment.
      Ce peut être utile pour réduire le nombre de descripteurs de fichiers
      consommés en travaillant avec de très grandes tables.
      Mais faites attention à ne pas choisir une valeur plus large que ce
      qui est supporté par votre plateforme et les systèmes de fichiers
      que vous voulez utiliser.
      D'autres outils que vous pourriez vouloir utiliser, comme
      tar, peuvent aussi poser des limites
      sur la taille de fichier utilisable.
      Il est recommandé que cette valeur soit une puissance de 2,
      même si ce n'est pas absolument nécessaire.
      Notez que changer cette valeur casse la compatibilité entre bases
      au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser
      pg_upgrade pour mettre à jour vers une
      version compilée avec une taille de segment différente.
     
--with-blocksize=TAILLEBLOC #
      Définit la taille de bloc (block size), en kilooctets.
      C'est l'unité de stockage et d'entrée-sortie dans les tables.
      Le défaut, 8 kilooctets, est adéquat pour la plupart des situations ;
      mais d'autres valeurs peuvent être utiles dans certains cas.
      La valeur peut être une puissance de 2 entre 1 et 32 (kilooctets).
      Notez que changer cette valeur casse la compatibilité entre bases
      au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser
      pg_upgrade pour mettre à jour vers une
      version compilée avec une taille de bloc différente.
     
--with-wal-blocksize=TAILLEBLOC #
      Définit la taille de bloc dans les journaux de transaction
      (WAL block size), en kilooctets.
      C'est l'unité de stockage et d'entrée-sortie en leur sein.
      Le défaut, 8 kilooctets, convient pour la plupart des situations ;
      mais d'autres valeurs peuvent être utiles dans certains cas.
      La valeur doit être une puissance de 2 entre 1 et 64 (kilooctets).
      Notez que changer cette valeur casse la compatibilité entre bases
      au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser
      pg_upgrade pour mettre à jour vers une
      version compilée avec une taille de bloc de WAL différente.
     
   La plupart des options de cette section n'ont d'intérêt
   que pour développer ou déboguer PostgreSQL.
   Elles ne sont pas recommandées pour la production, sauf
   --enable-debug, qui peut être utile pour
   obtenir des rapports de bugs détaillés, dans l'éventualité
   malheureuse où vous rencontriez un bug.
   Sur les plateformes supportant DTrace, --enable-dtrace
   peut raisonnablement être utilisé en production.
  
   Pour compiler une installation destinée à développer du code
   au sein du serveur, il est recommandé d'utiliser au moins
   les options --enable-debug
   et --enable-cassert.
  
--enable-debug #Compile tous les programmes et bibliothèques avec les symboles de débogage. Cela signifie que vous pouvez exécuter les programmes au sein d'un débogueur pour analyser les problèmes. Cela augmente considérablement la taille des exécutables et, avec des compilateurs autres que GCC, désactive habituellement les optimisations du compilateur, provoquant des ralentissements. Cependant, avoir les symboles en place est extrêmement utile pour traiter d'éventuels problèmes. Actuellement, cette option n'est recommandée pour les installations en production que si vous utilisez GCC. Néanmoins, vous devriez toujours l'utiliser si vous développez, ou si vous utilisez une version bêta.
--enable-cassert #Active les vérifications des assertions (assertion) dans le serveur, qui testent de nombreuses conditions qui « ne peuvent pas arriver ». C'est inestimable pour le développement du code, mais les tests peuvent ralentir le serveur considérablement. Activer ces tests ne va pas améliorer la stabilité de votre serveur ! Les tests des assertions ne sont pas triés par sévérité, et un petit bug relativement inoffensif, s'il déclenche un échec d'assertion, peut mener à des redémarrages du serveur ! Cette option n'est pas recommandée en production, mais vous devriez l'avoir en développement, ou en utilisant une version bêta.
--enable-tap-tests #
      Active les tests avec les outils TAP de Perl.
      Cela nécessite une installation de Perl et de son module
      IPC::Run.
      Voir Section 31.4 pour plus d'information.
     
--enable-depend #Active le suivi automatique des dépendances. Avec cette option, les makefiles sont conçus pour que tous les fichiers objets soient recompilés si n'importe quel fichier d'en-tête change. C'est utile si vous faites du développement, mais n'est que gaspillage si vous ne devez compiler qu'une fois pour installer. Pour le moment, cette option ne fonctionne qu'avec GCC.
--enable-coverage #Si vous utilisez GCC, tous 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 31.5 pour davantage d'informations. Cette option ne doit être utilisée qu'avec GCC et en développement.
--enable-profiling #
      En cas d'utilisation de GCC, tous les programmes et bibliothèques
      sont compilés pour pouvoir être profilés. À la sortie du
      processus serveur, un sous-répertoire sera créé pour contenir le
      fichier gmon.out contenant les données de profilage.
      Cette option n'est à utiliser qu'avec GCC et en développement.
     
--enable-dtrace #Compile PostgreSQL avec le support de l'outil de trace dynamique, DTrace. Voir Section 27.5 pour plus d'informations.
      Pour pointer vers le programme dtrace, la variable
      d'environnement DTRACE peut être configurée. Ce sera
      souvent nécessaire, car dtrace est typiquement
      installé sous /usr/sbin, qui peut ne pas être
      dans votre PATH.
     
      Des options supplémentaires en ligne de commande
      pour dtrace
      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 bits, ajoutez
      l'option DTRACEFLAGS="-64". 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-injection-points #Compile PostgreSQL avec le support des points d'injection dans le serveur. Les points d'injection permettent d'exécuter du code utilisateur à l'intérieur du serveur pour des chemins de code prédéfinis. Ceci aide aux tests et à l'investigation de scénarios parallélisés d'une façon contrôlé. Cette option est désactivée par défaut. Voir Section 36.10.13 pour plus de détails. Cette option a pour but d'être utilisée uniquement pour les tests des développeurs.
--with-segsize-blocks=SEGSIZE_BLOCKS #
      Précise la taille des segments des relations en blocs. Si
      --with-segsize et cette option sont toutes les deux
      précisées, cette option l'emporte. Cette option est seulement pour les
      développeurs, pour tester le code en relation aux segments.
     
configure #
  En plus des options de ligne de commande ordinaires décrites
  plus haut, configure répond à nombre
  de variables d'environnement.
  Vous pouvez les spécifier sur la ligne de commande de
  configure, par exemple ainsi :
  
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
  Dans ce cas, une variable d'environnement est peu différente d'une option de ligne de commande. Vous pouvez aussi les placer au préalable :
export CC=/opt/bin/gccexport CFLAGS='-O2 -pipe'./configure
Cette utilisation peut être pratique parce que les scripts de configuration de beaucoup de programmes répondent à ces variables de manière similaire.
  Les plus utilisées de ces variables d'environnement sont
  CC et CFLAGS.
  Si vous préférez utiliser un compilateur C différent de celui choisi par
  configure, positionnez la variable
  CC vers le compilateur de votre choix.
  Par défaut, configure choisira
  gcc s'il est disponible, et sinon celui par
  défaut sur la plateforme (habituellement cc).
  De façon similaire, vous pouvez repositionner les options par défaut du
  compilateur à l'aide de la variable CFLAGS.
 
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
      optimiser le code source lors de la compilation avec
      --with-llvm
     
CPP #préprocesseur C
CPPFLAGS #options à passer au préprocesseur C
CXX #compilateur C++
CXXFLAGS #options à passer au compilateur 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
LLVM_CONFIG #
      programme llvm-config à utiliser pour localiser
      l'installation LLVM.
     
MSGFMT #
      programme msgfmt pour le support des langues
     
PERL #
      programme interpréteur Perl. Il sera utilisé pour déterminer les
      dépendances pour la compilation 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 compilation de PL/Python. S'il n'est pas
      configuré, les chemins suivants sont testés dans cet ordre :
      python3 python.
     
TCLSH #
      programme interpréteur Tcl. Il sera utilisé pour déterminer
      les dépendances pour la compilation de PL/Tcl.
      Si ce paramètre n'est pas en place, seront testés dans cet ordre :
      tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85
      tclsh8.4 tclsh84.
     
XML2_CONFIG #
      programme xml2-config utilisé pour trouver
      l'emplacement de l'installation de libxml2.
     
  Parfois, ajouter des options de compilation après coup à celles
  choisies par configure peut se révéler utile.
  Un exemple parlant
  concerne l'option -Werror de
  gcc, qui ne peut pas être incluse dans la
  variable CFLAGS passée à configure,
  car elle casserait 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 make. Le contenu de
  COPT est ajouté aux variables CFLAGS et
  LDFLAGS configurées par configure.
  Par exemple, vous pouvez faire :
make COPT='-Werror'
  ou
export COPT='-Werror'make
   Si vous utilisez GCC, il est préférable de compiler avec un niveau
   d'optimisation d'au moins -O1, parce que l'absence
   d'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ébogage : un pas-à-pas sur le code
   compilé ne correspondra pas forcément directement aux lignes de code.
   Si vous avez du mal à déboguer du code optimisé, recompilez les fichiers
   qui vous intéressent avec -O0.
   Une façon simple de le faire est
   de passer une option à make:
   make PROFILE=-O0 file.o.
  
   En fait, les variables d'environnement COPT et
   PROFILE sont gérées de façon identique par les
   makefiles de PostgreSQL. Laquelle utiliser est
   une affaire de préférence, mais l'usage parmi les développeurs
   est d'utiliser PROFILE pour les ajustements ponctuels,
   alors que COPT peut être conservée en permanence.