Installation de PostgreSQL à partir du code source


Ce document décrit l'installation de PostgreSQL à partir de la présente distribution du code source.

Si vous construisez PostgreSQL pour Microsoft Windows, continuez la lecture de ce chapitre si vous avez pour but d'utiliser MinGW ou Cygwin ; par contre, si vous voulez utiliser Visual C++ de Microsoft, voir la documentation principale à la place.


Version courte

./configure
make
su
make install
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test

Le reste du chapitre est la version longue.


Prérequis

En général, les plateformes Unix modernes sont capables d'exécuter PostgreSQL. Les plateformes sur lesquelles des tests ont été effectués sont décrites dans la la section intitulée « Plateformes supportées » ci-après.

Les logiciels suivants sont nécessaires pour compiler PostgreSQL :

  • GNU make version 3.80 (ou une version plus récente) est nécessaire ; les autres programmes make ou les versions plus anciennes de GNU make *ne* fonctionnent *pas*. (GNU make est parfois installé sous le nom « gmake »). Pour connaître la version utilisée, saisir

    make --version

  • Il est nécessaire d'avoir un compilateur C ISO/ANSI (au minimum compatible avec C99). Une version récente de GCC est recommandée, mais PostgreSQL est connu pour compiler avec de nombreux compilateurs de différents vendeurs.

  • tar est requis pour déballer la distribution des sources, associé à gzip ou bzip2.

  • La bibliothèque GNU Readline est utilisée par défaut. Elle permet à psql (l'interpréteur de ligne de commandes SQL de PostgreSQL) de se souvenir de chaque commande saisie, et permet d'utiliser les flèches du clavier pour rappeler et éditer les commandes précédentes. C'est très pratique et fortement recommandé. Si vous n'en voulez pas, vous devrez renseigner l'option « --without-readline » lors de l'appel à la commande « configure ». Une alternative possible est l'utilisation de la bibliothèque « libedit » sous licence BSD, développée au départ sur NetBSD. La bibliothèque « libedit » est compatible GNU Readline, et est utilisée si cette dernière n'est pas trouvée, ou si l'option « --with-libedit-preferred » est fournie à « configure ». Si vous utilisez une distribution Linux à base de paquets, et que ceux de readline et readline-devel sont séparés, il faut impérativement installer les deux.

  • La bibliothèque de compression zlib est utilisée par défaut. Si vous n'en voulez pas, il faut préciser « --without-zlib » à « configure ». Cela a pour conséquence de désactiver le support des archives compressées dans pg_dump et pg_restore.

Les paquets suivants sont optionnels. S'ils ne sont pas obligatoires lors d'une compilation par défaut de PostgreSQL, ils le deviennent lorsque certaines options sont utilisées, comme cela est expliqué par la suite.

  • Pour compiler le langage procédural PL/Perl, une installation complète de Perl, comprenant la bibliothèque « libperl » et les fichiers d'en-tête est nécessaire. La version minimale requise est Perl 5.8.3.

    Comme PL/Perl est une bibliothèque partagée, la bibliothèque « libperl » doit aussi être partagée sur la plupart des plateformes. C'est désormais le choix par défaut dans les versions récentes de Perl, mais ce ne l'était pas dans les versions plus anciennes ; dans tous les cas, c'est du ressort de celui qui a installé Perl chez vous. « configure » échouera si la compilation de PL/Perl est sélectionnée, mais qu'il ne trouve pas une bibliothèque partagée « libperl ». Dans ce cas, vous devrez recompiler et installer Perl manuellement pour être capable de compiler PL/Perl. Lors du processus de configuration pour Perl, demandez une bibliothèque partagée.

    Si vous avez l'intention d'avoir plus qu'une utilisation occasionnelle de PL/Perl, vous devez vous assurer que l'installation de Perl a été faite avec l'option usemultiplicity activée (perl -V vous indiquera si c'est le cas).

  • Pour compiler le langage de programmation serveur PL/Python, il faut que Python soit installé avec les fichiers d'en-tête et le module distutils. La version minimum requise est Python 2.7. Python 3 est supporté s'il s'agit d'une version 3.2 ou ultérieure ; voir la the PL/Python documentation lors de l'utilisation de Python 3.

    Puisque PL/Python doit être une bibliothèque partagée, la bibliothèque « libpython » doit l'être aussi sur la plupart des plateformes. Ce n'est pas le cas des installations par défaut de Python compilées à partir des sources, mais une bibliothèque partagée est disponible dans de nombreuses distributions de systèmes d'exploitation. « configure » échouera si la compilation de PL/Python est sélectionnée et qu'il ne peut pas trouver une bibliothèque partagée « libpython ». Cela peut impliquer que vous deviez soit installer des packages supplémentaires, soit recompiler (une partie de) votre installation Python pour fournir cette bibliothèque partagée. Lors de la compilation à partir des sources, lancez le « configure » de Python avec l'option --enable-shared.

  • Pour compiler le langage procédural PL/Tcl, Tcl doit bien sûr être installé. La version minimale requise est Tcl 8.4.

  • Pour activer le support de langage natif (NLS), qui permet d'afficher les messages d'un programme dans une langue autre que l'anglais, une implémentation de l'API Gettext est nécessaire. Certains systèmes d'exploitation l'intègrent (par exemple, Linux, NetBSD, Solaris) ; pour d'autres systèmes, un paquet additionnel peut être téléchargé sur https://www.gnu.org/software/gettext/. Si vous utilisez l'implémentation Gettext des bibliothèques C GNU, certains utilitaires nécessiteront le paquet GNU Gettext. Il n'est pas nécessaire dans les autres implémentations.

  • Vous aurez besoin de OpenSSL, si vous voulez utiliser du chiffrement pour vos connexions clientes. OpenSSL est aussi requis pour la génération de nombres aléatoires sur les plateformes qui n'ont pas « /dev/urandom » (sauf Windows). La version minimale requise est la 1.0.1.

  • Vous avez besoin de Kerberos, OpenLDAP ou PAM pour bénéficier de l'authentification ou du chiffrement en utilisant ces services.

  • Vous avez besoin de LZ4 si vous voulez disposer de la compression de données avec cette méthode ; voir the configuration parameter default_toast_compression.

  • Pour compiler la documentation PostgreSQL, il existe un ensemble de prérequis séparé ; voir the main documentation's appendix on documentation.

Si vous compilez depuis une arborescence Git et non d'un paquet des sources publié, ou pour faire du développement au niveau serveur, les paquets suivants seront également nécessaires :

  • GNU Flex et Bison sont nécessaires pour compiler à partir d'un export du Git, ou si vous avez changé les fichiers de définition de l'analyseur ou du « scanner ». Au besoin, les versions nécessaires sont Flex 2.5.31 ou ultérieure et Bison 1.875 ou ultérieure. D'autres programmes lex et yacc ne peuvent pas être utilisés.

  • Perl 5.8.3 ou ultérieur est aussi nécessaire pour compiler les sources du Git, ou si vous avez changé les fichiers en entrée pour n'importe laquelle des étapes qui utilisent des scripts Perl. Sous Windows, Perl est nécessaire dans tous les cas. Perl est aussi nécessaire pour lancer certains jeux de tests.

Si vous avez besoin de récupérer un paquet GNU, vous le trouverez sur votre site miroir local de GNU (voir https://www.gnu.org/order/ftp.html pour la liste) ou sur ftp://ftp.gnu.org/gnu/.

Il est important de vérifier qu'il y a suffisamment d'espace disque disponible. 350 Mo sont nécessaires pour la compilation et 60 Mo pour le répertoire d'installation. Un groupe de bases de données vide nécessite 40 Mo ; les bases de données prennent environ cinq fois plus d'espace que des fichiers texte contenant les mêmes données. Si des tests de régression sont prévus, 300 Mo supplémentaires sont temporairement nécessaires. Utilisez la commande « df » pour vérifier l'espace disque disponible.


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 qui vous intéressent. Cela se 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 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_dir
    cd 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 la section intitulée « Options de configure ».

    « configure » tient aussi compte de certaines variables d'environnement, comme décrit dans la section intitulée « Variables d'environnement de configure ». Elle offre d'autres moyens de personnaliser la configuration.

  2. Compilation

    Pour démarrer la compilation, entrez l'un de ces ordres :

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

  3. 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 the file « src/test/regress/README » and the documentation 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.

  4. Installer les fichiers

    Note:

    Si vous mettez à jour un système existant, assurez-vous de lire the documentation, 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 install
    make -C src/include install
    make -C src/interfaces install
    make -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.


Options de 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.


Emplacements de l'installation

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 », ce qui signifie « /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 ». NB : 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 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 « 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 de PostgreSQL, formatée en HTML, sera installée dans ce répertoire. La valeur par défaut est « DATAROOTDIR ».

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


Fonctionnalités de PostgreSQL

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 la section intitulée « Prérequis ».

--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-icu

Compiler avec le support de la bibliothèque ICU, activant les collations ICU . Le paquet ICU4C doit être installé. Sa version minimum nécessaire est actuellement la 4.2.

Par défaut, pkg-config sera utilisé pour déterminer les options de compilation nécessaires. Cela est supporté pour ICU4C version 4.6 et suivantes. Pour des versions plus anciennes, ou si pkg-config n'est pas disponible, les variables ICU_CFLAGS et ICU_LIBS peuvent être fournies à « 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 par défaut du compilateur, vous aurez besoin de préciser des chaînes non vides pour éviter l'appel à pkg-config, par exemple ICU_CFLAGS=' '.)

--with-llvm

Compile avec le support de JIT, basé sur LLVM . Ceci nécessite l'installation de la bibliothèque LLVM. Sa version minimale requise est actuellement la 3.9.

« llvm-config » sera utilisé pour trouver les options de compilation nécessaires. « llvm-config », puis « llvm-config-$major-$minor » pour toutes les versions supportées, seront recherchés 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. Ceci permet l'utilisation de LZ4 pour la compression des données des tables.

--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. Sur beaucoup d'environnements, le système GSSAPI (habituellement une partie de l'installation 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 . 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. 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.


Anti-Fonctionnalités

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

--disable-thread-safety

Désactive la sécurité des threads pour les bibliothèques clients. Ceci interdit aux threads concurrents dans les programmes libpq et ECPG de contrôler en toute sécurité leurs pointeurs de connexion privés. N'utiliser que sur les plateformes avec un support des threads défaillant.


Détails du processus de compilation

--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 la section intitulée « Bibliothèques partagées » pour plus de détails.


Divers

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.


Options pour les développeurs

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.

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

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


Variables d'environnement de 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/gcc
export 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. 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.

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 compilation de PL/Perl.

PYTHON

programme interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la compilation 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 the PL/Python documentation pour plus d'informations. Si ce paramètre n'est pas en place, seront testés dans cet ordre : python python3 python2.

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
  

Note:

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.


Initialisation post-installation


Bibliothèques partagées

Sur certains systèmes gérant des bibliothèques partagées, il faut spécifier comment trouver les nouvelles bibliothèques partagées. Les systèmes sur lesquels ce n'est *pas* nécessaire comprennent FreeBSD, HP-UX, Linux, NetBSD, OpenBSD et Solaris.

La méthode pour le faire varie selon la plateforme, mais la plus répandue consiste à positionner la variable d'environnement LD_LIBRARY_PATH ainsi : avec les shells Bourne (« sh », « ksh », « bash », « zsh ») :

LD_LIBRARY_PATH=/usr/local/pgsql/lib
export LD_LIBRARY_PATH

ou en « csh » ou « tcsh » :

setenv LD_LIBRARY_PATH /usr/local/pgsql/lib

Remplacez /usr/local/pgsql/lib par la valeur donnée à « --libdir » dans l'Étape 1. Vous pouvez mettre ces commandes dans un script de démarrage tel que « /etc/profile » ou « ~/.bash_profile ». De bons conseils sur les mises en garde associées à cette méthode peuvent être trouvés sur http://xahlee.info/UnixResource_dir/_/ldpath.html.

Sur certains systèmes, il peut être préférable de renseigner la variable d'environnement LD_RUN_PATH *avant* la compilation.

Avec Cygwin, placez le répertoire des bibliothèques dans la variable PATH, ou déplacez les fichiers « .dll » dans le répertoire « bin ».

En cas de doute, référez-vous aux pages de man de votre système (peut-être « ld.so » ou « rld »). Si vous avez ultérieurement un message tel que

psql: error in loading shared libraries
libpq.so.2.1: cannot open shared object file: No such file or directory

alors cette étape est vraiment nécessaire. Occupez-vous en alors.

Si votre système d'exploitation est Linux et que vous avez les accès de super-utilisateur, vous pouvez exécuter :

/sbin/ldconfig /usr/local/pgsql/lib

(ou le répertoire équivalent) après l'installation pour permettre à l'éditeur de liens de trouver les bibliothèques partagées plus rapidement. Référez-vous aux pages man portant sur « ldconfig » pour plus d'informations. Pour les systèmes d'exploitation FreeBSD, NetBSD et OpenBSD, la commande est :

/sbin/ldconfig -m /usr/local/pgsql/lib

Les autres systèmes d'exploitation ne sont pas connus pour avoir de commande équivalente.


Variables d'environnement

Si l'installation a été réalisée dans « /usr/local/pgsql » ou à un autre chemin hors des répertoires où par défaut sont recherchés les exécutables, vous devez ajouter « /usr/local/pgsql/bin » (ou le répertoire fourni à « --bindir » au moment de l'Étape 1) dans votre PATH. À strictement parler, ce n'est pas une obligation, mais cela rendra l'utilisation de PostgreSQL plus confortable.

Pour ce faire, ajoutez ce qui suit dans le fichier d'initialisation de votre shell, comme « ~/.bash_profile » (ou « /etc/profile », si vous voulez que tous les utilisateurs l'aient) :

PATH=/usr/local/pgsql/bin:$PATH
export PATH

Si vous utilisez le « csh » ou le « tcsh », alors utilisez la commande :

set path = ( /usr/local/pgsql/bin $path )

Pour que votre système trouve la documentation man, il vous faut ajouter des lignes telles que celles qui suivent à votre fichier d'initialisation du shell, à moins que vous installiez ces pages dans un répertoire où elles sont recherchées normalement :

MANPATH=/usr/local/pgsql/share/man:$MANPATH
export MANPATH

Les variables d'environnement PGHOST et PGPORT indiquent aux applications clientes l'hôte et le port du serveur de base. Elles surchargent les valeurs utilisées lors de la compilation. Si vous exécutez des applications clientes à distance, alors il est plus pratique que tous les utilisateurs prévoyant d'utiliser la base de données paramètrent PGHOST. Ce n'est pas une obligation, cependant, la configuration peut être communiquée via les options de lignes de commande à la plupart des programmes clients.


Comment débuter

Ce qui suit est un résumé rapide de comment mettre en place PostgreSQL et de le faire tourner une fois installé. La documentation principale contient plus d'informations.

  1. Créez un compte utilisateur pour le serveur PostgreSQL. C'est l'utilisateur sous lequel le serveur tournera. Pour un usage en production, vous devez créer un compte séparé, non privilégié (« postgres » est généralement utilisé). Si vous n'avez pas d'accès root ou voulez juste expérimenter, votre propre compte utilisateur suffit ; par contre exécuter le serveur en tant que root est un risque pour la sécurité et ne fonctionnera pas.

    adduser postgres

  2. Créez une installation de base de données avec la commande « initdb ». Pour lancer « initdb », vous devez être connecté à votre compte utilisateur PostgreSQL. En tant que root, cela ne fonctionnera pas.

    root# mkdir /usr/local/pgsql/data
    root# chown postgres /usr/local/pgsql/data
    root# su - postgres
    postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

    L'option « -D » spécifie l'endroit où les données seront stockées. Vous pouvez utiliser n'importe quel chemin de votre choix, il n'a pas besoin d'être sous le répertoire d'installation. Soyez juste sûr que le compte serveur peut écrire sous ce répertoire d'installation (ou créez-le s'il n'existe pas déjà) avant de démarrer « initdb », comme illustré ici.

  3. À ce point, si vous n'avez pas utilisé « initdb » avec l'option -A, vous voudrez modifier « pg_hba.conf » pour contrôler les accès au serveur en local avant de le démarrer. Le défaut est de faire confiance à tous les utilisateurs locaux.

  4. À l'étape précédente, « initdb » a dû vous dire de démarrer le serveur de base de données. Faites-le maintenant. La commande devrait ressembler à quelque chose comme :

    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start

    Pour arrêter un serveur qui tourne en arrière-plan, vous pouvez taper :

    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stop

  5. Créez une base de données :

    /usr/local/pgsql/bin/createdb testdb

    Puis entrez :

    /usr/local/pgsql/bin/psql testdb

    pour vous connecter à cette base de données. Quand apparaît le prompt, vous pouvez entrer des commandes SQL et commencer à expérimenter.


Que faire maintenant ?

  • La distribution de PostgreSQL contient une documentation complète que vous devriez lire un jour. Après installation, la documentation est accessible en pointant votre navigateur vers « /usr/local/pgsql/doc/html/index.html  », si vous n'avez pas changé les répertoires d'installation.

    Les premiers chapitres de la documentation principale sont le tutoriel, et devraient être votre première lecture si vous êtes complètement novice en matière de base de données SQL. Si vous êtes familier avec les concepts de base de données, vous continuerez alors sur la partie sur l'administration d'un serveur, qui contient des informations sur comment mettre en place le serveur, les utilisateurs et l'authentification.

  • Généralement, vous voudrez modifier le système pour qu'il démarre le serveur de base de données dès son démarrage. Des suggestions pour cela figurent dans la documentation.

  • Lancez les tests de régression sur le serveur que vous venez d'installer (avec « make installcheck »). Si vous ne l'avez pas fait avant l'installation, vous devriez vraiment le faire maintenant. Ceci aussi est expliqué dans la documentation.

  • Par défaut PostgreSQL est configuré pour tourner sur un matériel minimaliste. Cela permet de le démarrer avec n'importe quelle configuration matérielle. Cependant, la configuration par défaut n'est pas conçue pour des performances optimales. Pour atteindre les meilleures performances, plusieurs paramètres du serveur doivent être ajustés, les deux principaux étant shared_buffers et work_mem. D'autres paramètres mentionnés dans la documentation affectent aussi les performances.


Plateformes supportées

Une plateforme (c'est-à-dire une combinaison d'un processeur et d'un système d'exploitation) est considérée comme supportée par la communauté des développeurs de PostgreSQL si le code permet le fonctionnement sur cette plateforme, et que la compilation et les tests de régression ont été récemment validés sur cette plateforme. Actuellement, la plupart des tests de compatibilité de plateforme se font automatiquement par des machines de tests dans la ferme de compilation de PostgreSQL. Si vous êtes intéressé par l'utilisation de PostgreSQL sur une plateforme qui n'est pas représentée dans la ferme de compilation, mais pour laquelle le code fonctionne ou peut fonctionner, nous vous suggérons fortement de monter une machine qui sera membre de la ferme pour que la compatibilité puisse être assurée dans la durée.

En général, PostgreSQL doit fonctionner sur les architectures processeur suivantes : x86, x86_64, IA64, PowerPC, PowerPC 64, S/390, S/390x, Sparc, Sparc 64, ARM, MIPS, MIPSEL et PA-RISC. Un support du code existe pour M68K, M32R et VAX, mais ces architectures n'ont pas été testées récemment à notre connaissance. Il est souvent possible de compiler PostgreSQL sur un type de processeur non supporté en précisant « --disable-spinlocks » ; mais les performances seront mauvaises.

De manière générale, PostgreSQL doit fonctionner sur les systèmes d'exploitation suivants : Linux (toutes les distributions récentes), Windows (XP et ultérieurs), FreeBSD, OpenBSD, NetBSD, macOS, AIX, HP/UX et Solaris. D'autres systèmes de type Unix peuvent aussi fonctionner, mais ne sont pas testés pour le moment. Dans la plupart des cas, toutes les architectures processeurs supportées par un système d'exploitation donné fonctionneront. Cherchez dans le répertoire la section intitulée « Notes spécifiques à des plateformes » ci-dessous pour voir s'il y a des informations spécifiques à votre système d'exploitation, tout particulièrement dans le cas d'un ancien système.

Si vous avez des problèmes d'installation sur une plateforme connue comme supportée d'après des résultats récents de la ferme de compilation, merci de rapporter cette information à . Si vous êtes intéressé pour porter PostgreSQL sur une nouvelle plateforme, est l'endroit approprié pour en discuter.


Notes spécifiques à des plateformes

Cette section documente des problèmes spécifiques additionnels liés à des plateformes, en ce qui concerne l'installation et le paramétrage de PostgreSQL. Assurez-vous de lire aussi les instructions d'installation, et en particulier la section intitulée « Prérequis ». Par ailleurs, consultez the file « src/test/regress/README » and the documentation à propos de l'interprétation des tests de régression.

Les plateformes qui ne sont pas traitées ici n'ont pas de problèmes d'installation spécifiques connus.


AIX

Pour construire PostgreSQL à partir des sources sur macOS, vous aurez besoin d'installer les outils développeur en ligne de commande d'Apple, ce qui se fait en exécutant

xcode-select --install

(notez que cela affichera une fenêtre graphique pour confirmation). Vous pouvez aussi installer Xcode.

PostgreSQL fonctionne sur AIX, mais les versions avant la 6.1 ont différents problèmes et ne sont pas recommandées. Vous pouvez utiliser soit GCC, soit le compilateur natif IBM « xlc ».


Gestion de la mémoire

AIX est particulier dans la façon dont il gère la mémoire. Vous pouvez avoir un serveur avec des gigaoctets de mémoire libre, et malgré tout avoir des erreurs de mémoire insuffisante ou des erreurs d'espace d'adressage quand vous lancez des applications. Un exemple est le chargement d'extensions qui échoue avec des erreurs inhabituelles. Par exemple, en exécutant en tant que propriétaire de l'installation PostgreSQL :

=# CREATE EXTENSION plperl;
ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
   

En l'exécutant en tant que non-propriétaire, mais dans le groupe propriétaire de l'installation PostgreSQL :

=# CREATE EXTENSION plperl;
ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
   

On a un autre exemple avec les erreurs out of memory dans les traces du serveur PostgreSQL, avec toutes les allocations de mémoire vers 256 Mo ou plus qui échouent.

La cause générale de ces problèmes est le nombre de bits et le modèle mémoire utilisés par le processus serveur. Par défaut, tous les binaires compilés sur AIX sont 32 bits. Cela ne dépend pas du matériel ou du noyau en cours d'utilisation. Ces processus 32 bits sont limités à 4 Go de mémoire, présentée en segments de 256 Mo utilisant un modèle parmi quelques-uns. Le modèle par défaut permet moins de 256 Mo dans le tas, comme il partage un seul segment avec la pile.

Dans le cas de l'exemple plperl ci-dessus, vérifiez votre umask et les droits des binaires de l'installation PostgreSQL. Les binaires de l'exemple étaient en 32 bits et installés en mode 750 au lieu de 755. En raison de ces droits, seul le propriétaire ou un membre du groupe propriétaire peut charger la bibliothèque. Puisqu'il n'est pas lisible par tout le monde, le chargeur place l'objet dans le tas du processus au lieu d'un segment de mémoire de bibliothèque où il aurait été sinon placé.

La solution « idéale » est d'utiliser une version 64-bits de PostgreSQL, mais ce n'est pas toujours pratique, parce que les systèmes équipés de processeurs 32 bits peuvent compiler, mais pas exécuter, des binaires 64 bits.

Si un binaire 32 bits est souhaité, positionnez LDR_CNTRL à MAXDATA=0xn0000000, où 1<=n <= 8 avant de démarrer le serveur PostgreSQL, et essayez différentes valeurs et paramètres de « postgresql.conf » pour trouver une configuration qui fonctionne de façon satisfaisante. Cette utilisation de LDR_CNTRL notifie à AIX que vous voulez que le serveur réserve MAXDATA octets pour le tas, alloués en segments de 256 Mo. Quand vous avez trouvé une configuration utilisable, « ldedit » peut être utilisé pour modifier les binaires pour qu'ils utilisent par défaut la taille de tas désirée. PostgreSQL peut aussi être recompilé, en passant à configure LDFLAGS="-Wl,-bmaxdata:0xn0000000" pour obtenir le même résultat.

Pour une compilation en 64 bits, positionnez OBJECT_MODE à 64 et passez CC="gcc -maix64" et LDFLAGS="-Wl,-bbigtoc" à « configure ». (Les options pour « xlc » pourraient différer.) Si vous omettez les exports de OBJECT_MODE, votre compilation échouera avec des erreurs de l'éditeur de liens. Lorsque OBJECT_MODE est positionné, il indique aux outils de compilation d'AIX comme « ar », « as » et « ld » quel type de fichiers à manipuler par défaut.

Par défaut, de la surallocation d'espace de pagination peut se produire. Bien que nous ne l'ayons jamais constaté, AIX tuera des processus quand il se trouvera à court de mémoire et que la zone surallouée sera accédée. Le comportement le plus proche de ceci que nous ayons constaté est l'échec d'un fork, parce que le système avait décidé qu'il n'y avait plus de suffisamment de mémoire disponible pour un nouveau processus. Comme beaucoup d'autres parties d'AIX, la méthode d'allocation de l'espace de pagination et l'arrêt suite à un « out-of-memory » sont configurables, soit pour le système, soit pour un processus, si cela devient un problème.


Cygwin

PostgreSQL peut être compilé avec Cygwin, un environnement similaire à Linux pour Windows, mais cette méthode est inférieure à la version native Windows (voir the documentation) et faire tourner un serveur sur Cygwin n'est plus recommandé.

Quand vous compilez à partir des sources, suivant la procédure d'installation de style Unix (c'est-à-dire ./configure; make;, etc.), notez les différences suivantes spécifiques à Cygwin :

  • Positionnez le PATH pour utiliser le répertoire binaire Cygwin avant celui des utilitaires Windows. Cela évitera des problèmes à la compilation.

  • La commande « adduser » n'est pas supportée ; utilisez les outils appropriés de gestion d'utilisateurs sous Windows NT, 2000 ou XP. Sinon, sautez cette étape.

  • La commande « su » n'est pas supportée ; utilisez ssh pour simuler la commande « su » sous Windows NT, 2000 ou XP. Sinon, sautez cette étape.

  • OpenSSL n'est pas supporté.

  • Démarrez « cygserver » pour le support de la mémoire partagée. Pour cela, entrez la commande /usr/sbin/cygserver &. Ce programme doit fonctionner à chaque fois que vous démarrez le serveur PostgreSQL ou que vous initialisez un cluster de bases de données (« initdb »). La configuration par défaut de « cygserver » pourrait nécessiter des changements (par exemple, augmenter SEMMNS) pour éviter à PostgreSQL d'échouer en raison d'un manque de ressources système.

  • Il se peut que la compilation échoue sur certains systèmes quand une locale autre que C est utilisée. Pour résoudre ce problème, positionnez la locale à C avec la commande « export LANG=C.utf8 » avant de lancer la compilation, puis, une fois PostgreSQL installé, repositionnez-là à son ancienne valeur.

  • Les tests de régression en parallèle (make check) peuvent générer des échecs de tests de régression aléatoires en raison d'un dépassement de capacité de la file d'attente de listen() qui cause des erreurs de connexion refusée ou des blocages. Vous pouvez limiter le nombre de connexions en utilisant la variable de make MAX_CONNECTIONS comme ceci :

    make MAX_CONNECTIONS=5 check
         

    (Sur certains systèmes, vous pouvez avoir jusqu'à 10 connexions simultanées).

Il est possible d'installer « cygserver » et le serveur PostgreSQL en tant que services Windows NT. Pour plus d'informations sur comment le faire, veuillez vous référer au document « README » inclus avec le package binaire PostgreSQL sur Cygwin. Il est installé dans le répertoire « /usr/share/doc/Cygwin ».


macOS

Sur les versions récentes de macOS, il est nécessaire d'embarquer le chemin « sysroot » dans les options d'inclusion utilisées pour trouver les fichiers d'en-tête système. Ceci a pour résultat la génération d'un script configure variant suivant la version du SDK utilisée durant configure. Ceci ne devrait pas poser de problèmes dans les scénarios simples, mais si vous essayez de faire quelque chose comme compiler une extension sur une machine différente de celle sur laquelle le code serveur a été compilé, vous pouvez avoir besoin de forcer l'utilisation d'un chemin sysroot différent. Pour cela, configurez PG_SYSROOT ainsi

make PG_SYSROOT=/desired/path all
  

Pour trouver le chemin approprié sur votre machine, lancez

xcrun --show-sdk-path
  

Notez que compiler une extension en utilisant une version sysroot différente de celle utilisée pour compiler le serveur n'est pas vraiment recommandée ; dans le pire des cas, cela peut entraîner des incohérences d'ABI difficiles à débugger.

Vous pouvez aussi sélectionner un chemin sysroot différent de celui par défaut lors du configure en indiquant PG_SYSROOT à configure :

./configure ... PG_SYSROOT=/desired/path
  

Ceci sera principalement utile pour faire de la cross-compilation pour d'autres versions de macOS. Il n'y a pas de garantie que les exécutables qui vont en résulter fonctionneront sur l'hôte actuel.

Pour supprimer les options « -isysroot », utilisez

./configure ... PG_SYSROOT=none

(tout nom de chemin non existant fonctionnera). Ceci pourrait être utile si vous souhaitez compiler avec un compilateur autre que celui d'Apple, mais attention au fait que ce cas n'est ni testé ni supporté par les développeurs PostgreSQL.

La fonctionnalité « System Integrity Protection » (SIP) de macOS casse make check, car elle empêche de transmettre la configuration nécessaire de DYLD_LIBRARY_PATH vers les exécutables en cours de tests. Vous pouvez contourner cela en exécutant make install avant make check. Ceci étant dit, la plupart des développeurs Postgres désactivent simplement SIP.


MinGW/Windows Natif

PostgreSQL pour Windows peut être compilé en utilisant MinGW, un environnement de compilation similaire à celui disponible sous Unix pour les systèmes d'exploitation Microsoft, ou en utilisant la suite de compilation Visual C++ de Microsoft. La variante de compilation MinGW utilise le système de compilation normal décrit dans ce chapitre ; la compilation via Visual C++ fonctionne de façon totalement différente, et est décrite dans the documentation.

Le port natif Windows requiert une version 32 ou 64 bits de Windows 2000 ou ultérieurs. Les systèmes d'exploitation antérieurs n'ont pas l'infrastructure nécessaire (mais Cygwin peut être utilisé pour ceux-ci). MinGW, le système de compilation similaire à Unix, et MSYS, une suite d'outils Unix nécessaires pour exécuter des scripts shell tels que « configure », peuvent être téléchargés à partir de http://www.mingw.org/. Aucun de ces outils n'est nécessaire pour exécuter les binaires générés ; ils ne sont nécessaires que pour créer les binaires.

Pour compiler les binaires 64 bits avec MinGW, installez l'ensemble d'outils 64 bits à partir de https://mingw-w64.org/, ajoutez le répertoire des binaires de MinGW dans la variable d'environnement PATH, et lancez la commande « configure » avec l'option « --host=x86_64-w64-mingw32 ».

Après que vous avez tout installé, il vous est conseillé de lancer psql dans « CMD.EXE », car la console MSYS a des problèmes de tampons.


Récupérer des dumps suite aux plantages sous Windows

Si PostgreSQL sous Windows plante, il peut générer des minidumps qui peuvent être utilisés pour dépister la cause du plantage ; ils sont semblables aux core dumps d'Unix. Vous pouvez lire ces dumps avec Windows Debugger Tools ou avec Visual Studio. Pour permettre la génération des dumps sous Windows, créez un sous-répertoire nommé « crashdumps » dans le répertoire des données du cluster. Ainsi les dumps seront écrits dans ce répertoire avec un nom unique généré à partir de l'identifiant du processus planté et du moment du plantage.


Solaris

PostgreSQL est bien supporté sous Solaris. Plus le système d'exploitation est à jour, moins vous aurez de problèmes.


Outils requis

Vous pouvez compiler soit avec GCC, soit avec le compilateur de Sun. Pour une meilleure optimisation du code, le compilateur de Sun est fortement recommandé sur l'architecture SPARC. Si vous utilisez le compilateur de Sun, attention à ne pas sélectionner « /usr/ucb/cc » ; utilisez « /opt/SUNWspro/bin/cc ».

Vous pouvez télécharger Sun Studio sur https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. De nombreux outils GNU sont intégrés dans Solaris 10, ou sont présents sur le Solaris companion CD. Si vous avez besoin des packages pour des versions plus anciennes de Solaris, vous pouvez trouver ces outils sur http://www.sunfreeware.com. Si vous préférez les sources, allez sur https://www.gnu.org/order/ftp.html.


configure se plaint d'un programme de test en échec

Si « configure » se plaint d'un programme de test en échec, il s'agit probablement de l'éditeur de lien à l'exécution qui ne trouve pas une bibliothèque, probablement libz, libreadline ou une autre bibliothèque non standard telle que libssl. Pour lui indiquer le bon endroit, positionnez la variable d'environnement LDFLAGS sur la ligne de commande de « configure », par exemple,

configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
   

Voir la man page de ld pour plus d'informations.


Compiler pour des performances optimales

Sur l'architecture SPARC, Sun Studio est fortement recommandé pour la compilation. Essayez d'utiliser l'option d'optimisation « -xO5 » pour générer des binaires sensiblement plus rapides. N'utilisez pas d'options modifiant le comportement des opérations à virgule flottante ni le traitement de errno (par exemple, « -fast »).

Si vous n'avez pas de raison d'utiliser des binaires 64 bits sur SPARC, préférez la version 32 bits. Les opérations et les binaires 64 bits sont plus lents que les variantes 32 bits. D'un autre côté, le code 32 bits sur un processeur de la famille AMD64 n'est pas natif, donc le code 32 bits est significativement plus lent sur cette famille de processeurs.


Utiliser DTrace pour tracer PostgreSQL

Oui, l'utilisation de DTrace est possible. Voir the documentation pour davantage d'informations.

Si vous voyez l'édition de liens de l'exécutable « postgres » échouer avec un message d'erreur similaire à :

Undefined                       first referenced
 symbol                             in file
AbortTransaction                    utils/probes.o
CommitTransaction                   utils/probes.o
ld: fatal: Symbol referencing errors. No output written to postgres
collect2: ld returned 1 exit status
make: *** [postgres] Error 1
   

l'installation DTrace est trop ancienne pour gérer les sondes dans les fonctions statiques. Solaris 10u4 ou plus récent est nécessaire pour utiliser DTrace.