Installation de PostgreSQL a partir du code source ------------------------------------------------------------------------ Ce document decrit l'installation de PostgreSQL a partir de la presente 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 a 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. ------------------------------------------------------------------------ Prerequis En general, les plateformes Unix modernes sont capables d'executer PostgreSQL. Les plateformes sur lesquelles des tests ont ete effectues sont decrites dans la la section intitulee << Plateformes supportees >> ci-apres. Les logiciels suivants sont necessaires pour compiler PostgreSQL : - GNU make version 3.80 (ou une version plus recente) est necessaire ; les autres programmes make ou les versions plus anciennes de GNU make *ne* fonctionnent *pas*. (GNU make est parfois installe sous le nom << gmake >>). Pour connaitre la version utilisee, saisir make --version - Il est necessaire d'avoir un compilateur C ISO/ANSI (au minimum compatible avec C99). Une version recente de GCC est recommandee, mais PostgreSQL est connu pour compiler avec de nombreux compilateurs de differents vendeurs. - tar est requis pour deballer la distribution des sources, associe a gzip ou bzip2. - La bibliotheque GNU Readline est utilisee par defaut. Elle permet a psql (l'interpreteur de ligne de commandes SQL de PostgreSQL) de se souvenir de chaque commande saisie, et permet d'utiliser les fleches du clavier pour rappeler et editer les commandes precedentes. C'est tres pratique et fortement recommande. Si vous n'en voulez pas, vous devrez renseigner l'option << --without-readline >> lors de l'appel a la commande << configure >>. Une alternative possible est l'utilisation de la bibliotheque << libedit >> sous licence BSD, developpee au depart sur NetBSD. La bibliotheque << libedit >> est compatible GNU Readline, et est utilisee si cette derniere n'est pas trouvee, ou si l'option << --with-libedit-preferred >> est fournie a << configure >>. Si vous utilisez une distribution Linux a base de paquets, et que ceux de readline et readline-devel sont separes, il faut imperativement installer les deux. - La bibliotheque de compression zlib est utilisee par defaut. Si vous n'en voulez pas, il faut preciser << --without-zlib >> a << configure >>. Cela a pour consequence de desactiver le support des archives compressees dans pg_dump et pg_restore. Les paquets suivants sont optionnels. S'ils ne sont pas obligatoires lors d'une compilation par defaut de PostgreSQL, ils le deviennent lorsque certaines options sont utilisees, comme cela est explique par la suite. - Pour compiler le langage procedural PL/Perl, une installation complete de Perl, comprenant la bibliotheque << libperl >> et les fichiers d'en-tete est necessaire. La version minimale requise est Perl 5.8.3. Comme PL/Perl est une bibliotheque partagee, la bibliotheque << libperl >> doit aussi etre partagee sur la plupart des plateformes. C'est desormais le choix par defaut dans les versions recentes de Perl, mais ce ne l'etait pas dans les versions plus anciennes ; dans tous les cas, c'est du ressort de celui qui a installe Perl chez vous. << configure >> echouera si la compilation de PL/Perl est selectionnee, mais qu'il ne trouve pas une bibliotheque partagee << libperl >>. Dans ce cas, vous devrez recompiler et installer Perl manuellement pour etre capable de compiler PL/Perl. Lors du processus de configuration pour Perl, demandez une bibliotheque partagee. 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 ete faite avec l'option usemultiplicity activee (perl -V vous indiquera si c'est le cas). - Pour compiler le langage de programmation serveur PL/Python, il faut que Python soit installe avec les fichiers d'en-tete et le module distutils. La version minimum requise est Python 2.7. Python 3 est supporte s'il s'agit d'une version 3.2 ou ulterieure ; voir la the PL/Python documentation lors de l'utilisation de Python 3. Puisque PL/Python doit etre une bibliotheque partagee, la bibliotheque << libpython >> doit l'etre aussi sur la plupart des plateformes. Ce n'est pas le cas des installations par defaut de Python compilees a partir des sources, mais une bibliotheque partagee est disponible dans de nombreuses distributions de systemes d'exploitation. << configure >> echouera si la compilation de PL/Python est selectionnee et qu'il ne peut pas trouver une bibliotheque partagee << libpython >>. Cela peut impliquer que vous deviez soit installer des packages supplementaires, soit recompiler (une partie de) votre installation Python pour fournir cette bibliotheque partagee. Lors de la compilation a partir des sources, lancez le << configure >> de Python avec l'option --enable-shared. - Pour compiler le langage procedural PL/Tcl, Tcl doit bien sur etre installe. 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 implementation de l'API Gettext est necessaire. Certains systemes d'exploitation l'integrent (par exemple, Linux, NetBSD, Solaris) ; pour d'autres systemes, un paquet additionnel peut etre telecharge sur http://www.gnu.org/software/gettext/. Si vous utilisez l'implementation Gettext des bibliotheques C GNU, certains utilitaires necessiteront le paquet GNU Gettext. Il n'est pas necessaire dans les autres implementations. - Vous aurez besoin de OpenSSL, si vous voulez utiliser du chiffrement pour vos connexions clientes. OpenSSL est aussi requis pour la generation de nombres aleatoires 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 beneficier de l'authentification ou du chiffrement en utilisant ces services. - Pour compiler la documentation PostgreSQL, il existe un ensemble de prerequis separe ; voir the main documentation's appendix on documentation. Si vous compilez depuis une arborescence Git et non d'un paquet des sources publie, ou pour faire du developpement au niveau serveur, les paquets suivants seront egalement necessaires : - GNU Flex et Bison sont necessaires pour compiler a partir d'un export du Git, ou si vous avez change les fichiers de definition de l'analyseur ou du << scanner >>. Au besoin, les versions necessaires sont Flex 2.5.31 ou ulterieure et Bison 1.875 ou ulterieure. D'autres programmes lex et yacc ne peuvent pas etre utilises. - Perl 5.8.3 ou ulterieur est aussi necessaire pour compiler les sources du Git, ou si vous avez change les fichiers en entree pour n'importe laquelle des etapes qui utilisent des scripts Perl. Sous Windows, Perl est necessaire dans tous les cas. Perl est aussi necessaire pour lancer certains jeux de tests. Si vous avez besoin de recuperer 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 verifier qu'il y a suffisamment d'espace disque disponible. 350 Mo sont necessaires pour la compilation et 60 Mo pour le repertoire d'installation. Un groupe de bases de donnees vide necessite 40 Mo ; les bases de donnees prennent environ cinq fois plus d'espace que des fichiers texte contenant les memes donnees. Si des tests de regression sont prevus, 300 Mo supplementaires sont temporairement necessaires. Utilisez la commande << df >> pour verifier l'espace disque disponible. ------------------------------------------------------------------------ Procedure d'installation 1. Configuration La premiere etape de la procedure d'installation est de configurer l'arborescence systeme et de choisir les options qui vous interessent. Cela se fait en executant le script << configure >>. Pour une installation par defaut, entrer simplement ./configure Ce script executera de nombreux tests afin de determiner les valeurs de certaines variables dependantes du systeme, et de detecter certaines specificites de votre systeme d'exploitation. Il creera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a ete trouve. Pour garder une arborescence de compilation separee de celle des sources, << configure >> peut etre execute a partir d'un repertoire hors de l'arborescence des sources, ou la compilation s'effectuera. Cette procedure est aussi appelee 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 defaut compilera le serveur et les outils, ainsi que toutes les applications clientes et les interfaces ne necessitant qu'un compilateur C. Tous les fichiers seront installes par defaut sous << /usr/local/pgsql >>. Les processus de compilation et d'installation peuvent etre personnalises en fournissant une ou plusieurs options de ligne de commande a << configure >>. Generalement, vous allez personnaliser l'endroit de l'installation, ou la liste des fonctionnalites optionnelles a compiler. << configure >> a beaucoup d'options, decrites dans la section intitulee << Options de configure >>. << configure >> tient aussi compte de certaines variables d'environnement, comme decrit dans la section intitulee << Variables d'environnement de configure >>. Elle offre d'autres moyens de personnaliser la configuration. 2. Compilation Pour demarrer la compilation, entrez l'un de ces ordres : make make all (Rappelez-vous qu'il faut GNU make.) La duree de la compilation sera de quelques minutes, et depend de votre materiel. La derniere ligne affichee doit etre : All of PostgreSQL successfully made. Ready to install. Si vous voulez compiler tout ce qui peut l'etre, dont la documentation (HTML et pages de manuel) et les modules optionnels (<< contrib >>), entrez plutot : make world La derniere ligne affichee doit etre : PostgreSQL, contrib, and documentation successfully made. Ready to install. Si vous voulez compiler tout ce qui peut etre compile, en incluant les modules supplementaires (<< contrib >>), mais sans la documentation, saisissez a la place : make world-bin Si vous voulez lancer la compilation depuis un autre makefile plutot que manuellement, vous devez desactiver la variable MAKELEVEL ou la mettre a zero, par exemple ainsi : build-postgresql: $(MAKE) -C postgresql MAKELEVEL=0 all L'oublier peut mener a d'etranges messages d'erreur, typiquement sur des fichiers d'en-tete manquants. 3. Tests de regression Si, avant de l'installer, vous voulez tester ce serveur nouvellement compile, vous devez lancer les tests de regression maintenant. Il s'agit d'une suite de tests pour verifier que PostgreSQL fonctionne sur votre machine de la maniere prevue par ses developpeurs. Entrez : make check (Cela ne fonctionnera pas en tant que root ; faites-le en tant qu'utilisateur non privilegie.) Voir the file << src/test/regress/README >> and the documentation pour des informations detaillees sur l'interpretation des resultats des tests. Vous pouvez repeter ces tests n'importe quand par la suite en entrant la meme commande. 4. Installer les fichiers Note: Si vous mettez a jour un systeme existant, assurez-vous de lire the documentation, qui contient des instructions sur la mise a jour d'une instance. Pour installer PostgreSQL, entrez : make install Cela installera les fichiers dans les repertoires specifies dans Etape 1. Assurez-vous que vous avez les droits necessaires pour y ecrire. Normalement, vous devez faire cela en tant que root. Une alternative est de creer les repertoires cibles par avance, et de vous arranger pour obtenir les permissions adequates. Si vous voulez tout construire, sauf la documentation, saisissez a la place : make install-world-bin Pour installer la documentation (HTML et pages de manuel), entrez : make install-docs Si vous avez entre make world plus haut, entrez plutot : make install-world Cela va installer aussi la documentation. Vous pouvez aussi utiliser make install-strip au lieu de make install pour debarrasser les fichiers executables et les bibliotheques de leurs informations de debogage lors de l'installation. Cela economisera un peu d'espace disque. Dans une compilation avec le support du debogage, cette purge va supprimer ce support ; ce n'est donc a faire que s'il n'y a plus besoin de debogage. install-strip reussit assez bien a economiser de l'espace, mais ne sait pas toujours effacer le moindre octet inutile d'un executable ; pour recuperer tout l'espace disque possible, vous devrez donc terminer manuellement. L'installation standard fournit tous les fichiers d'en-tete necessaires au developpement d'applications clientes, comme pour celui cote serveur, par exemple pour des fonctions specifiques ou des types de donnees codes en C. (Avant PostgreSQL 8.0, un make install-all-headers separe etait necessaire pour le deuxieme cas, mais cette etape a ete integree dans l'installation standard.) Installation cliente : Si vous voulez installer uniquement les applications clientes et les bibliotheques 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. Desinstallation : Pour annuler l'installation, utilisez la commande << make uninstall >>. Cependant, cela ne supprimera pas tous les repertoires qui ont ete crees. Nettoyage : Apres l'installation, vous pouvez liberer de l'espace disque en supprimant les fichiers compiles de l'arborescence des sources avec la commande << make clean >>. Cela preservera les fichiers crees par << configure >>, pour que vous puissiez tout recompiler plus tard avec << make >>. Pour reinitialiser l'arbre des sources dans l'etat ou il est distribue, utilisez << make distclean >>. Si vous voulez compiler pour plusieurs plateformes au sein de la meme 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 modifiees.) Si, apres compilation, vous decouvrez que vos options a << configure >> etaient fausses, ou si vous changez quelque chose que << configure >> a pris en compte (par exemple, par une mise a jour logicielle), il est conseille de faire << make distclean >> avant de reconfigurer et recompiler. Sans cela, vos choix de configuration pourraient ne pas se propager a tous les endroits necessaires. ------------------------------------------------------------------------ Options de configure Les parametres en ligne de commande a << configure >> sont expliques ci-dessous. Cette liste n'est pas exhaustive (utilisez ./configure --help pour en avoir une qui le soit). Les options non evoquees ici sont destinees a des utilisations avancees, comme la compilation croisee, et figurent dans la documentation standard d'Autoconf. ------------------------------------------------------------------------ Emplacements de l'installation Ces options controlent ou make install va poser les fichiers. L'option << --prefix >> est suffisante dans la plupart des cas. Pour des besoins specifiques, vous pouvez personnaliser les sous-repertoires d'installation avec d'autres options decrites dans cette section. Attention : changer les emplacements relatifs des differents sous-repertoires peut rendre l'installation non deplacable, c'est-a-dire que vous ne pourrez plus la deplacer par la suite. (Les emplacements pour man et doc ne sont pas concernes par cette restriction.) Pour obtenir des installations deplacables, vous pouvez utiliser l'option --disable-rpath decrite plus bas. --prefix=PREFIX Installe tous les fichiers dans le repertoire << PREFIX >> au lieu du repertoire << /usr/local/pgsql >>. Les fichiers eux-memes seront installes dans divers sous-repertoires ; aucun fichier ne sera directement installe sous << PREFIX >>. --exec-prefix=EXEC-PREFIX Les fichiers qui dependent de l'architecture peuvent etre installes dans un repertoire avec un prefixe different, << EXEC-PREFIX >>, different de celui donne par << PREFIX >>. Cela peut etre utile pour partager entre plusieurs machines les fichiers independants de l'architecture. S'il est omis, << EXEC-PREFIX >> est egal a << PREFIX >>, et les fichiers dependants seront installes sous la meme arborescence que les fichiers independants de l'architecture, ce qui est probablement le but recherche. --bindir=REPERTOIRE Indique le repertoire des executables. Par defaut, il s'agit de << EXEC-PREFIX/bin >>, ce qui signifie << /usr/local/pgsql/bin >>. --sysconfdir=REPERTOIRE Precise le repertoire de divers fichiers de configuration, par defaut << PREFIX/etc >>. --libdir=REPERTOIRE Precise le repertoire d'installation des bibliotheques et des modules chargeables dynamiquement. Par defaut, il s'agit de << EXEC-PREFIX/lib >>. --includedir=REPERTOIRE Precise le repertoire d'installation des fichiers d'en-tete C et C++. Par defaut, il s'agit de << PREFIX/include >>. --datarootdir=REPERTOIRE Indique le repertoire racine de differents types de fichiers de donnees en lecture seule. Cela ne sert qu'a parametrer des valeurs par defaut pour certaines des options suivantes. La valeur par defaut est << PREFIX/share >>. --datadir=REPERTOIRE Indique le repertoire pour les fichiers de donnees en lecture seule utilises par les programmes installes. La valeur par defaut est << DATAROOTDIR >>. NB : cela n'a aucun rapport avec l'endroit ou les fichiers de base de donnees seront places. --localedir=REPERTOIRE Indique le repertoire pour installer les donnees de localisation, en particulier les fichiers des catalogues de traduction des messages. La valeur par defaut est << DATAROOTDIR/locale >>. --mandir=REPERTOIRE Les pages de manuel fournies avec PostgreSQL seront installees sous ce repertoire, dans leur sous-repertoire << manx >> respectif. Par defaut, il s'agit de << DATAROOTDIR/man >>. --docdir=REPERTOIRE Configure le repertoire racine pour installer les fichiers de documentation, sauf les pages << man >>. Ceci ne positionne la valeur par defaut que pour les options suivantes. La valeur par defaut pour cette option est << DATAROOTDIR/doc/postgresql >>. --htmldir=REPERTOIRE La documentation de PostgreSQL, formatee en HTML, sera installee dans ce repertoire. La valeur par defaut est << DATAROOTDIR >>. Note: Une attention toute particuliere a ete prise afin de rendre possible l'installation de PostgreSQL dans des repertoires partages (comme << /usr/local/include >>), sans interferer avec l'espace de noms du reste du systeme. En premier lieu, le mot << /postgresql >> est automatiquement ajoute aux repertoires datadir, sysconfdir et docdir, a moins que le nom du repertoire a partir de la racine ne contienne deja le mot << postgres >> ou << pgsql >>. Par exemple, si << /usr/local >> est choisi comme prefixe, la documentation sera installee dans << /usr/local/doc/postgresql >> ; mais si le prefixe est << /opt/postgres >>, alors ce sera dans << /opt/postgres/doc >>. Les fichiers d'en-tete C publics pour les interfaces clientes sont installes sous includedir, et sont independants de l'espace de noms du systeme. Les fichiers d'en-tete internes et ceux du serveur sont installes dans des repertoires prives sous includedir. Voir la documentation de chaque interface pour savoir comment obtenir ces fichiers d'en-tete. Enfin, si necessaire, un repertoire prive sera aussi cree sous libdir, pour les modules chargeables dynamiquement. ------------------------------------------------------------------------ Fonctionnalites de PostgreSQL Les options decrites dans cette section permettent d'ajouter diverses fonctionnalites de PostgreSQL qui ne sont pas compilees par defaut ; pour la plupart a cause du besoin d'autres logiciels, comme decrit dans la section intitulee << Prerequis >>. --enable-nls[=LANGUES] Active le support des langues natives (NLS), c'est-a-dire la capacite 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, separes par une espace ; par exemple, --enable-nls='de fr' (l'intersection entre la liste et l'ensemble des langues traduites actuellement sera calculee automatiquement). En l'absence de liste, toutes les traductions disponibles seront installees. Pour utiliser cette option, une implementation de l'API Gettext est necessaire. --with-perl Permet la compilation du langage cote serveur PL/Perl --with-python Permet la compilation du langage cote serveur PL/Python. --with-tcl Permet la compilation du langage cote serveur PL/Tcl. --with-tclconfig=REPERTOIRE Tcl installe le fichier << tclConfig.sh >>, qui contient des informations de configuration necessaires pour compiler le module d'interfacage avec Tcl. Ce fichier est normalement trouve automatiquement a un emplacement connu, mais pour utiliser une version differente de Tcl, il faut indiquer le repertoire ou chercher << tclConfig.sh >>. --with-icu Compiler avec le support de la bibliotheque ICU, activant les collations ICU . Le paquet ICU4C doit etre installe. Sa version minimum necessaire est actuellement la 4.2. Par defaut, pkg-config sera utilise pour determiner les options de compilation necessaires. Cela est supporte 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 etre fournies a << 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 defaut du compilateur, vous aurez besoin de preciser des chaines non vides pour eviter l'appel a pkg-config, par exemple ICU_CFLAGS=' '.) --with-llvm Compile avec le support de JIT, base sur LLVM . Ceci necessite l'installation de la bibliotheque LLVM. Sa version minimale requise est actuellement la 3.9. << llvm-config >> sera utilise pour trouver les options de compilation necessaires. << llvm-config >>, puis << llvm-config-$major-$minor >> pour toutes les versions supportees, seront recherches dans votre PATH. Au cas ou le bon programme n'est pas trouve, il faut utiliser la variable LLVM_CONFIG pour specifier le chemin du bon << llvm-config >>. Par exemple : ./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config' Le support de LLVM necessite un compilateur << clang >> compatible (a specifier, si necessaire, avec la variable d'environnement CLANG), et un compilateur C++ fonctionnel (a specifier, si necessaire, avec la variable d'environnement CXX). --with-openssl Compile avec le support pour les connexions SSL (avec chiffrement). Le paquet OpenSSL doit etre installe. << configure >> verifiera les fichiers d'en-tete et les bibliotheques pour s'assurer que votre installation d'OpenSSL est suffisante avant de continuer. --with-gssapi Compile avec le support de l'authentification GSSAPI. Sur beaucoup d'environnements, le systeme GSSAPI (habituellement une partie de l'installation Kerberos) n'est pas installe dans un endroit recherche par defaut (par exemple << /usr/include >> ou << /usr/lib >>) ; vous devez donc ajouter aussi les options << --with-includes >> et << --with-libraries >>. << configure >> verifiera les fichiers d'en-tete et les bibliotheques 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 parametres de connexion . Sur Unix, cela requiert l'installation du paquet OpenLDAP. Sur Windows, la bibliotheque WinLDAP est utilisee par defaut. << configure >> verifiera l'existence des fichiers d'en-tete et des bibliotheques necessaires 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 systeme de notifications systemd. Ceci ameliore l'integration si le serveur est demarre par systemd, mais n'a pas d'impact sinon. libsystemd et les fichiers d'en-tete associes doivent etre installes pour utiliser cette option. --with-bonjour Compile avec le support du service de decouverte automatique Bonjour. Cela necessite le support de Bonjour dans votre systeme d'exploitation. Recommande sur macOS. --with-uuid=LIBRARY Compile le module uuid-ossp (qui fournit des fonctions pour generer des UUID), en utilisant la bibliotheque UUID specifiee. << LIBRARY >> doit correspondre a une de ces valeurs : - << bsd >> pour utiliser les fonctions UUID trouvees dans FreeBSD, NetBSD et d'autres systemes derives de BSD - << e2fs >> pour utiliser la bibliotheque UUID creee par le projet e2fsprogs ; cette bibliotheque est presente sur la plupart des systemes Linux et sur macOS, et peut etre obtenue sur d'autres plateformes egalement - << ossp >> pour utiliser la bibliotheque OSSP UUID --with-ossp-uuid Equivalent obsolete de --with-uuid=ossp. --with-libxml Compile avec libxml2, activant ainsi le support de SQL/XML. Une version 2.6.23 ou ulterieure de libxml2 est requise pour cette fonctionnalite. Pour detecter les options requises pour le compilateur et l'editeur de liens, PostgreSQL va demander a << pkg-config >>, s'il est installe et s'il connait libxml2. Sinon, le programme << xml2-config >>, qui est installe par libxml2, sera utilise s'il est trouve. L'utilisation de << pkg-config >> est preferee, parce qu'elle gere mieux les installations multiarchitectures. Pour utiliser une installation libxml2 situee dans un emplacement inhabituel, vous pouvez configurer les variables d'environnement relatives a << pkg-config >> (voir sa documentation), ou configurer la variable d'environnement XML2_CONFIG pour qu'elle pointe sur le programme << xml2-config >> appartenant a l'installation libxml2, ou configurer les variables XML2_CFLAGS et XML2_LIBS. (Si << pkg-config >> est installe, alors, pour surcharger son idee de l'emplacement de libxml2, vous devez renseigner soit XML2_CONFIG, soit XML2_CFLAGS et XML2_LIBS, avec des chaines non vides.) --with-libxslt Compile avec libxslt, activant le module xml2 pour operer des transformations XSL sur du XML. << --with-libxml >> doit etre specifie aussi. ------------------------------------------------------------------------ Anti-Fonctionnalites Les options decrites dans cette section permettent de desactiver certaines fonctionnalites de PostgreSQL compilees par defaut, mais que vous pouvez desactiver si ne sont pas disponibles un logiciel ou des fonctionnalites systeme necessaires. L'utilisation de ces options n'est pas recommandee si ce n'est pas vraiment necessaire. --without-readline Empeche l'utilisation de la bibliotheque Readline (et libedit par la meme occasion). Cette option desactive l'edition de la ligne de commande et l'historique dans psql. --with-libedit-preferred Favorise l'utilisation de la bibliotheque libedit (licence BSD). Cette option n'est importante que si vous avez les deux librairies installees ; le defaut dans ce cas est d'utiliser Readline. --without-zlib Empeche l'utilisation de la bibliotheque Zlib. Cela desactive le support des archives compressees dans pg_dump et pg_restore. --disable-spinlocks Autorise le succes de la compilation meme si PostgreSQL n'a pas le support des spinlocks pour le CPU de la plateforme. Ce manque de support entrainera des performances tres faibles ; du coup, cette option ne devra etre utilisee que si la compilation echoue et vous informe du manque de support des spinlocks sur votre plateforme. Si cette option est necessaire pour y compiler PostgreSQL, merci de rapporter le probleme a ses developpeurs. --disable-atomics Desactive l'utilisation des operations atomiques sur le CPU. Cette option ne fait rien sur les plateformes qui n'ont pas ces operations. Sur celles qui l'ont, cela entrainera de mauvaises performances. Cette option n'est utile que pour le debogage ou pour des comparatifs de performance. --disable-thread-safety Desactive la securite des threads pour les bibliotheques clients. Ceci interdit aux threads concurrents dans les programmes libpq et ECPG de controler en toute securite leurs pointeurs de connexion prives. N'utiliser que sur les plateformes avec un support des threads defaillant. ------------------------------------------------------------------------ Details du processus de compilation --with-includes=REPERTOIRES << REPERTOIRES >> est une liste de repertoires, separes par le caractere deux points (:), qui seront ajoutes a la liste de ceux ou le compilateur recherche des fichiers d'en-tete. Si vous avez des paquets optionnels (comme GNU Readline) installes 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=REPERTOIRES << REPERTOIRES >> est une liste de repertoires, separes par le caractere deux points (:), ou chercher des bibliotheques de fonctions. Si vous avez des paquets installes 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=REPERTOIRE PostgreSQL inclut sa propre base de donnees des fuseaux horaires, necessaire pour les operations sur les dates et les heures. Cette base de donnees est en fait compatible avec la base de fuseaux horaires IANA fournie par de nombreux systemes d'exploitation comme FreeBSD, Linux et Solaris, donc il semble redondant de l'installer une nouvelle fois. Quand cette option est utilisee, la base des fuseaux horaires fournie par le systeme, dans << REPERTOIRE >>, est utilisee a la place de celle incluse dans la distribution des sources de PostgreSQL. << REPERTOIRE >> doit etre indique avec un chemin absolu. << /usr/share/zoneinfo >> est un repertoire courant sur certains systemes d'exploitation. Notez que la routine d'installation ne detectera pas les donnees de fuseau horaire differentes ou erronees. Si vous utilisez cette option, il est conseille de lancer les tests de regression pour verifier que les donnees de fuseau horaire que vous pointez fonctionnent correctement avec PostgreSQL. Cette option est surtout destinee aux distributeurs de paquets binaires, qui connaissent bien leur systeme d'exploitation. Le principal avantage de cette option est que le paquet de PostgreSQL n'aura pas besoin de mise a jour a chaque changement des regles des fuseaux horaires. Un autre avantage est que PostgreSQL peut etre cross-compile plus simplement si les fichiers des fuseaux horaires n'ont pas besoin d'etre construits lors de l'installation. --with-extra-version=CHAINE Ajoute << CHAINE >> au numero de version de PostgreSQL. Par exemple, vous pouvez utiliser cela pour marquer des binaires compiles depuis des snapshots Git, ou contenant des patchs, avec une chaine supplementaire, comme un identifiant << git describe >> ou un numero de version de distribution du paquet. --disable-rpath N'indique pas aux executables de PostgreSQL qu'ils doivent chercher les bibliotheques partagees dans le repertoire des bibliotheques de l'installation (voir << --libdir >>). Sur la plupart des plateformes, cette indication utilise un chemin absolu vers le repertoire des bibliotheques, et sera inutile si vous deplacez l'installation plus tard. Cependant, vous devrez alors fournir aux executables un autre moyen pour trouver les bibliotheques partagees. Typiquement, cela implique de configurer l'editeur de liens du systeme d'exploitation pour les rechercher ; voir la section intitulee << Bibliotheques partagees >> pour plus de details. ------------------------------------------------------------------------ Divers Il est assez courant, particulierement pour les compilations de test, de modifier le numero de port avec l'option << --with-pgport >>. Les autres options de cette section ne sont recommandees que pour les utilisateurs avances. --with-pgport=PORT Positionne << PORT >> comme numero de port pour les serveurs et les clients. Le defaut est 5432. Le port peut toujours etre change plus tard ; mais, si vous le specifiez ici, serveur et clients auront le meme defaut des la compilation, ce qui peut etre tres pratique. D'habitude, la seule bonne raison de selectionner une autre valeur que le defaut est si vous avez l'intention de faire tourner plusieurs serveurs PostgreSQL sur la meme machine. --with-krb-srvnam=NOM Le nom par defaut du service principal Kerberos utilise par GSSAPI. postgres est le defaut. D'habitude, il n'y a aucune raison de changer cela, a moins que vous ne compiliez pour un environnement Windows auquel cas ce doit etre, en majuscules, POSTGRES. --with-segsize=SEGSIZE Definit la taille d'un segment (segment size), en gigaoctets. Au niveau du systeme d'exploitation, les grandes tables sont divisees en plusieurs fichiers, chacun d'une taille egale a la taille d'un segment. Cela evite des problemes avec les limites de taille de fichiers qui existent sur beaucoup de plateformes. La taille par defaut, 1 gigaoctet, est une valeur sure pour toutes les plateformes supportees. Si votre systeme 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 etre utile pour reduire le nombre de descripteurs de fichiers consommes en travaillant avec de tres grandes tables. Mais faites attention a ne pas choisir une valeur plus large que ce qui est supporte par votre plateforme et les systemes 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 recommande que cette valeur soit une puissance de 2, meme si ce n'est pas absolument necessaire. Notez que changer cette valeur casse la compatibilite entre bases au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser << pg_upgrade >> pour mettre a jour vers une version compilee avec une taille de segment differente. --with-blocksize=TAILLEBLOC Definit la taille de bloc (block size), en kilooctets. C'est l'unite de stockage et d'entree-sortie dans les tables. Le defaut, 8 kilooctets, est adequat pour la plupart des situations ; mais d'autres valeurs peuvent etre utiles dans certains cas. La valeur peut etre une puissance de 2 entre 1 et 32 (kilooctets). Notez que changer cette valeur casse la compatibilite entre bases au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser << pg_upgrade >> pour mettre a jour vers une version compilee avec une taille de bloc differente. --with-wal-blocksize=TAILLEBLOC Definit la taille de bloc dans les journaux de transaction (WAL block size), en kilooctets. C'est l'unite de stockage et d'entree-sortie en leur sein. Le defaut, 8 kilooctets, convient pour la plupart des situations ; mais d'autres valeurs peuvent etre utiles dans certains cas. La valeur doit etre une puissance de 2 entre 1 et 64 (kilooctets). Notez que changer cette valeur casse la compatibilite entre bases au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser << pg_upgrade >> pour mettre a jour vers une version compilee avec une taille de bloc de WAL differente. ------------------------------------------------------------------------ Options pour les developpeurs La plupart des options de cette section n'ont d'interet que pour developper ou deboguer PostgreSQL. Elles ne sont pas recommandees pour la production, sauf << --enable-debug >>, qui peut etre utile pour obtenir des rapports de bugs detailles, dans l'eventualite malheureuse ou vous rencontriez un bug. Sur les plateformes supportant DTrace, << --enable-dtrace >> peut raisonnablement etre utilise en production. Pour compiler une installation destinee a developper du code au sein du serveur, il est recommande d'utiliser au moins les options << --enable-debug >> et << --enable-cassert >>. --enable-debug Compile tous les programmes et bibliotheques avec les symboles de debogage. Cela signifie que vous pouvez executer les programmes au sein d'un debogueur pour analyser les problemes. Cela augmente considerablement la taille des executables et, avec des compilateurs autres que GCC, desactive habituellement les optimisations du compilateur, provoquant des ralentissements. Cependant, avoir les symboles en place est extremement utile pour traiter d'eventuels problemes. Actuellement, cette option n'est recommandee pour les installations en production que si vous utilisez GCC. Neanmoins, vous devriez toujours l'utiliser si vous developpez, ou si vous utilisez une version beta. --enable-cassert Active les verifications des assertions (assertion) dans le serveur, qui testent de nombreuses conditions qui << ne peuvent pas arriver >>. C'est inestimable pour le developpement du code, mais les tests peuvent ralentir le serveur considerablement. Activer ces tests ne va pas ameliorer la stabilite de votre serveur ! Les tests des assertions ne sont pas tries par severite, et un petit bug relativement inoffensif, s'il declenche un echec d'assertion, peut mener a des redemarrages du serveur ! Cette option n'est pas recommandee en production, mais vous devriez l'avoir en developpement, ou en utilisant une version beta. --enable-tap-tests Active les tests avec les outils TAP de Perl. Cela necessite une installation de Perl et de son module IPC::Run. --enable-depend Active le suivi automatique des dependances. Avec cette option, les makefiles sont concus pour que tous les fichiers objets soient recompiles si n'importe quel fichier d'en-tete change. C'est utile si vous faites du developpement, 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 bibliotheques sont compiles avec de l'instrumentation de test de couverture de code. Quand ils sont executes, ils generent des fichiers dans le repertoire de compilation avec des metriques de couverture de code. Cette option ne doit etre utilisee qu'avec GCC et en developpement. --enable-profiling En cas d'utilisation de GCC, tous les programmes et bibliotheques sont compiles pour pouvoir etre profiles. A la sortie du processus serveur, un sous-repertoire sera cree pour contenir le fichier << gmon.out >> contenant les donnees de profilage. Cette option n'est a utiliser qu'avec GCC et en developpement. --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 etre configuree. Ce sera souvent necessaire, car << dtrace >> est typiquement installe sous << /usr/sbin >>, qui peut ne pas etre dans votre PATH. Des options supplementaires en ligne de commande pour << dtrace >> peuvent etre indiquees dans la variable d'environnement DTRACEFLAGS pour le programme << dtrace >>. Sur Solaris, pour inclure le support de DTrace dans un executable 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 decrites plus haut, << configure >> repond a nombre de variables d'environnement. Vous pouvez les specifier 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 differente d'une option de ligne de commande. Vous pouvez aussi les placer au prealable : export CC=/opt/bin/gcc export CFLAGS='-O2 -pipe' ./configure Cette utilisation peut etre pratique parce que les scripts de configuration de beaucoup de programmes repondent a ces variables de maniere similaire. Les plus utilisees de ces variables d'environnement sont CC et CFLAGS. Si vous preferez utiliser un compilateur C different de celui choisi par << configure >>, positionnez la variable CC vers le compilateur de votre choix. Par defaut, << configure >> choisira << gcc >> s'il est disponible, et sinon celui par defaut sur la plateforme (habituellement << cc >>). De facon similaire, vous pouvez repositionner les options par defaut du compilateur a l'aide de la variable CFLAGS. Voici une liste des variables importantes qui sont configurables de cette facon : BISON programme Bison CC compilateur C CFLAGS options a passer au compilateur C CLANG chemin vers le programme << clang >> utilise pour optimiser le code source lors de la compilation avec --with-llvm CPP preprocesseur C CPPFLAGS options a passer au preprocesseur C CXX compilateur C++ CXXFLAGS options a passer au compilateur C++ DTRACE emplacement du programme << dtrace >> DTRACEFLAGS options a passer au programme << dtrace >> FLEX programme Flex LDFLAGS options a utiliser lors de l'edition des liens des executables et des bibliotheques partagees LDFLAGS_EX options supplementaires valables uniquement lors de l'edition des liens des executables LDFLAGS_SL options supplementaires valables uniquement lors de l'edition des liens des bibliotheques partagees LLVM_CONFIG programme << llvm-config >> a utiliser pour localiser l'installation LLVM. MSGFMT programme << msgfmt >> pour le support des langues PERL programme interpreteur Perl. Il sera utilise pour determiner les dependances pour la compilation de PL/Perl. La valeur par defaut est << perl >>. PYTHON chemin complet vers l'interpreteur Python. Il sera utilise pour determiner les dependances pour la compilation de PL/Python. De plus, si Python 2 ou 3 est specifie ici (ou implicitement choisi), il determine la variante de PL/Python qui devient disponible. Si vous preferez utiliser un compilateur C different de ceux listes par << configure >>, positionnez la variable d'environnement CC pour qu'elle pointe sur le compilateur de votre choix. Par defaut, << configure >> pointe sur << gcc >> s'il est disponible, sinon il utilise celui par defaut de la plateforme (habituellement << cc >>). De facon similaire, vous pouvez repositionner les options par defaut du compilateur a l'aide de la variable CFLAGS. Les variables d'environnement peuvent etre indiquees 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 facon : BISON programme Bison CC compilateur C CFLAGS options a passer au compilateur C CPP preprocesseur C CPPFLAGS options a passer au preprocesseur C DTRACE emplacement du programme << dtrace >> DTRACEFLAGS options a passer au programme << dtrace >> FLEX programme Flex LDFLAGS options a utiliser lors de l'edition des liens des executables et des bibliotheques partagees LDFLAGS_EX options supplementaires valables uniquement lors de l'edition des liens des executables LDFLAGS_SL options supplementaires valables uniquement lors de l'edition des liens des bibliotheques partagees MSGFMT programme << msgfmt >> pour le support des langues PERL chemin complet vers l'interpreteur Perl. Il sera utilise pour determiner les dependances pour la compilation de PL/Perl. PYTHON programme interpreteur Python. Il sera utilise pour determiner les dependances pour la compilation de PL/Python. De plus, si Python 2 ou 3 est specifie ici (ou implicitement choisi), il determine la variante de PL/Python qui devient disponible. Voir the PL/Python documentation pour plus d'informations. Si ce parametre n'est pas en place, seront testes dans cet ordre : python python3 python2. TCLSH programme interpreteur Tcl. Il sera utilise pour determiner les dependances pour la compilation de PL/Tcl. Si ce parametre n'est pas en place, seront testes dans cet ordre : tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84. XML2_CONFIG programme << xml2-config >> utilise pour trouver l'emplacement de l'installation de libxml2. Parfois, ajouter des options de compilation apres coup a celles choisies par << configure >> peut se reveler utile. Un exemple parlant concerne l'option << -Werror >> de gcc, qui ne peut pas etre incluse dans la variable CFLAGS passee a << 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'execution de << make >>. Le contenu de COPT est ajoute aux variables CFLAGS et LDFLAGS configurees par << configure >>. Par exemple, vous pouvez faire : make COPT='-Werror' ou export COPT='-Werror' make Note: Si vous utilisez GCC, il est preferable de compiler avec un niveau d'optimisation d'au moins << -O1 >>, parce que l'absence d'optimisation (<< -O0 >>) desactive aussi certains messages importants du compilateur (comme l'utilisation de variables non initialisees). Neanmoins, les niveaux d'optimisations peuvent compliquer le debogage : un pas-a-pas sur le code compile ne correspondra pas forcement directement aux lignes de code. Si vous avez du mal a deboguer du code optimise, recompilez les fichiers qui vous interessent avec << -O0 >>. Une facon simple de le faire est de passer une option a make: << make PROFILE=-O0 file.o >>. En fait, les variables d'environnement COPT et PROFILE sont gerees de facon identique par les makefiles de PostgreSQL. Laquelle utiliser est une affaire de preference, mais l'usage parmi les developpeurs est d'utiliser PROFILE pour les ajustements ponctuels, alors que COPT peut etre conservee en permanence. ------------------------------------------------------------------------ Initialisation post-installation ------------------------------------------------------------------------ Bibliotheques partagees Sur certains systemes gerant des bibliotheques partagees, il faut specifier comment trouver les nouvelles bibliotheques partagees. Les systemes sur lesquels ce n'est *pas* necessaire comprennent FreeBSD, HP-UX, Linux, NetBSD, OpenBSD et Solaris. La methode pour le faire varie selon la plateforme, mais la plus repandue consiste a 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 donnee a << --libdir >> dans l'Etape 1. Vous pouvez mettre ces commandes dans un script de demarrage tel que << /etc/profile >> ou << ~/.bash_profile >>. De bons conseils sur les mises en garde associees a cette methode peuvent etre trouves sur http://xahlee.info/UnixResource_dir/_/ldpath.html. Sur certains systemes, il peut etre preferable de renseigner la variable d'environnement LD_RUN_PATH *avant* la compilation. Avec Cygwin, placez le repertoire des bibliotheques dans la variable PATH, ou deplacez les fichiers << .dll >> dans le repertoire << bin >>. En cas de doute, referez-vous aux pages de man de votre systeme (peut-etre << ld.so >> ou << rld >>). Si vous avez ulterieurement 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 etape est vraiment necessaire. Occupez-vous en alors. Si votre systeme d'exploitation est Linux et que vous avez les acces de superutilisateur, vous pouvez executer : /sbin/ldconfig /usr/local/pgsql/lib (ou le repertoire equivalent) apres l'installation pour permettre a l'editeur de liens de trouver les bibliotheques partagees plus rapidement. Referez-vous aux pages man portant sur << ldconfig >> pour plus d'informations. Pour les systemes d'exploitation FreeBSD, NetBSD et OpenBSD, la commande est : /sbin/ldconfig -m /usr/local/pgsql/lib Les autres systemes d'exploitation ne sont pas connus pour avoir de commande equivalente. ------------------------------------------------------------------------ Variables d'environnement Si l'installation a ete realisee dans << /usr/local/pgsql >> ou a un autre chemin hors des repertoires ou par defaut sont recherches les executables, vous devez ajouter << /usr/local/pgsql/bin >> (ou le repertoire fourni a << --bindir >> au moment de l'Etape 1) dans votre PATH. A 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 systeme trouve la documentation man, il vous faut ajouter des lignes telles que celles qui suivent a votre fichier d'initialisation du shell, a moins que vous installiez ces pages dans un repertoire ou elles sont recherchees normalement : MANPATH=/usr/local/pgsql/share/man:$MANPATH export MANPATH Les variables d'environnement PGHOST et PGPORT indiquent aux applications clientes l'hote et le port du serveur de base. Elles surchargent les valeurs utilisees lors de la compilation. Si vous executez des applications clientes a distance, alors il est plus pratique que tous les utilisateurs prevoyant d'utiliser la base de donnees parametrent PGHOST. Ce n'est pas une obligation, cependant, la configuration peut etre communiquee via les options de lignes de commande a la plupart des programmes clients. ------------------------------------------------------------------------ Comment debuter Ce qui suit est un resume rapide de comment mettre en place PostgreSQL et de le faire tourner une fois installe. La documentation principale contient plus d'informations. 1. Creez un compte utilisateur pour le serveur PostgreSQL. C'est l'utilisateur sous lequel le serveur tournera. Pour un usage en production, vous devez creer un compte separe, non privilegie (<< postgres >> est generalement utilise). Si vous n'avez pas d'acces root ou voulez juste experimenter, votre propre compte utilisateur suffit ; par contre executer le serveur en tant que root est un risque pour la securite et ne fonctionnera pas. adduser postgres 2. Creez une installation de base de donnees avec la commande << initdb >>. Pour lancer << initdb >>, vous devez etre connecte a 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 >> specifie l'endroit ou les donnees seront stockees. Vous pouvez utiliser n'importe quel chemin de votre choix, il n'a pas besoin d'etre sous le repertoire d'installation. Soyez juste sur que le compte serveur peut ecrire sous ce repertoire d'installation (ou creez-le s'il n'existe pas deja) avant de demarrer << initdb >>, comme illustre ici. 3. A ce point, si vous n'avez pas utilise << initdb >> avec l'option -A, vous voudrez modifier << pg_hba.conf >> pour controler les acces au serveur en local avant de le demarrer. Le defaut est de faire confiance a tous les utilisateurs locaux. 4. A l'etape precedente, << initdb >> a du vous dire de demarrer le serveur de base de donnees. Faites-le maintenant. La commande devrait ressembler a quelque chose comme : /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start Pour arreter un serveur qui tourne en arriere-plan, vous pouvez taper : /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stop 5. Creez une base de donnees : /usr/local/pgsql/bin/createdb testdb Puis entrez : /usr/local/pgsql/bin/psql testdb pour vous connecter a cette base de donnees. Quand apparait le prompt, vous pouvez entrer des commandes SQL et commencer a experimenter. ------------------------------------------------------------------------ Que faire maintenant ? - La distribution de PostgreSQL contient une documentation complete que vous devriez lire un jour. Apres installation, la documentation est accessible en pointant votre navigateur vers << /usr/local/pgsql/doc/html/index.html >>, si vous n'avez pas change les repertoires d'installation. Les premiers chapitres de la documentation principale sont le tutoriel, et devraient etre votre premiere lecture si vous etes completement novice en matiere de base de donnees SQL. Si vous etes familier avec les concepts de base de donnees, 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. - Generalement, vous voudrez modifier le systeme pour qu'il demarre le serveur de base de donnees des son demarrage. Des suggestions pour cela figurent dans la documentation. - Lancez les tests de regression 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 explique dans la documentation. - Par defaut PostgreSQL est configure pour tourner sur un materiel minimaliste. Cela permet de le demarrer avec n'importe quelle configuration materielle. Cependant, la configuration par defaut n'est pas concue pour des performances optimales. Pour atteindre les meilleures performances, plusieurs parametres du serveur doivent etre ajustes, les deux principaux etant shared_buffers et work_mem. D'autres parametres mentionnes dans la documentation affectent aussi les performances. ------------------------------------------------------------------------ Plateformes supportees Une plateforme (c'est-a-dire une combinaison d'un processeur et d'un systeme d'exploitation) est consideree comme supportee par la communaute des developpeurs de PostgreSQL si le code permet le fonctionnement sur cette plateforme, et que la compilation et les tests de regression ont ete recemment valides sur cette plateforme. Actuellement, la plupart des tests de compatibilite de plateforme se font automatiquement par des machines de tests dans la ferme de compilation de PostgreSQL. Si vous etes interesse par l'utilisation de PostgreSQL sur une plateforme qui n'est pas representee dans la ferme de compilation, mais pour laquelle le code fonctionne ou peut fonctionner, nous vous suggerons fortement de monter une machine qui sera membre de la ferme pour que la compatibilite puisse etre assuree dans la duree. En general, 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 ete testees recemment a notre connaissance. Il est souvent possible de compiler PostgreSQL sur un type de processeur non supporte en precisant << --disable-spinlocks >> ; mais les performances seront mauvaises. De maniere generale, PostgreSQL doit fonctionner sur les systemes d'exploitation suivants : Linux (toutes les distributions recentes), Windows (XP et ulterieurs), FreeBSD, OpenBSD, NetBSD, macOS, AIX, HP/UX et Solaris. D'autres systemes de type Unix peuvent aussi fonctionner, mais ne sont pas testes pour le moment. Dans la plupart des cas, toutes les architectures processeurs supportees par un systeme d'exploitation donne fonctionneront. Cherchez dans le repertoire la section intitulee << Notes specifiques a des plateformes >> ci-dessous pour voir s'il y a des informations specifiques a votre systeme d'exploitation, tout particulierement dans le cas d'un ancien systeme. Si vous avez des problemes d'installation sur une plateforme connue comme supportee d'apres des resultats recents de la ferme de compilation, merci de rapporter cette information a . Si vous etes interesse pour porter PostgreSQL sur une nouvelle plateforme, est l'endroit approprie pour en discuter. ------------------------------------------------------------------------ Notes specifiques a des plateformes Cette section documente des problemes specifiques additionnels lies a des plateformes, en ce qui concerne l'installation et le parametrage de PostgreSQL. Assurez-vous de lire aussi les instructions d'installation, et en particulier la section intitulee << Prerequis >>. Par ailleurs, consultez the file << src/test/regress/README >> and the documentation a propos de l'interpretation des tests de regression. Les plateformes qui ne sont pas traitees ici n'ont pas de problemes d'installation specifiques connus. ------------------------------------------------------------------------ AIX Pour construire PostgreSQL a partir des sources sur macOS, vous aurez besoin d'installer les outils developpeur en ligne de commande d'Apple, ce qui se fait en executant xcode-select --install (notez que cela affichera une fenetre graphique pour confirmation). Vous pouvez aussi installer Xcode. PostgreSQL fonctionne sur AIX, mais les versions avant la 6.1 ont differents problemes et ne sont pas recommandees. Vous pouvez utiliser soit GCC, soit le compilateur natif IBM << xlc >>. ------------------------------------------------------------------------ Gestion de la memoire AIX est particulier dans la facon dont il gere la memoire. Vous pouvez avoir un serveur avec des gigaoctets de memoire libre, et malgre tout avoir des erreurs de memoire insuffisante ou des erreurs d'espace d'adressage quand vous lancez des applications. Un exemple est le chargement d'extensions qui echoue avec des erreurs inhabituelles. Par exemple, en executant en tant que proprietaire 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'executant en tant que non-proprietaire, mais dans le groupe proprietaire 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 memoire vers 256 Mo ou plus qui echouent. La cause generale de ces problemes est le nombre de bits et le modele memoire utilises par le processus serveur. Par defaut, tous les binaires compiles sur AIX sont 32 bits. Cela ne depend pas du materiel ou du noyau en cours d'utilisation. Ces processus 32 bits sont limites a 4 Go de memoire, presentee en segments de 256 Mo utilisant un modele parmi quelques-uns. Le modele par defaut 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, verifiez votre umask et les droits des binaires de l'installation PostgreSQL. Les binaires de l'exemple etaient en 32 bits et installes en mode 750 au lieu de 755. En raison de ces droits, seul le proprietaire ou un membre du groupe proprietaire peut charger la bibliotheque. 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 memoire de bibliotheque ou il aurait ete sinon place. La solution << ideale >> est d'utiliser une version 64-bits de PostgreSQL, mais ce n'est pas toujours pratique, parce que les systemes equipes de processeurs 32 bits peuvent compiler, mais pas executer, des binaires 64 bits. Si un binaire 32 bits est souhaite, positionnez LDR_CNTRL a MAXDATA=0xn0000000, ou 1<=n <= 8 avant de demarrer le serveur PostgreSQL, et essayez differentes valeurs et parametres de << postgresql.conf >> pour trouver une configuration qui fonctionne de facon satisfaisante. Cette utilisation de LDR_CNTRL notifie a AIX que vous voulez que le serveur reserve MAXDATA octets pour le tas, alloues en segments de 256 Mo. Quand vous avez trouve une configuration utilisable, << ldedit >> peut etre utilise pour modifier les binaires pour qu'ils utilisent par defaut la taille de tas desiree. PostgreSQL peut aussi etre recompile, en passant a configure LDFLAGS="-Wl,-bmaxdata:0xn0000000" pour obtenir le meme resultat. Pour une compilation en 64 bits, positionnez OBJECT_MODE a 64 et passez CC="gcc -maix64" et LDFLAGS="-Wl,-bbigtoc" a << configure >>. (Les options pour << xlc >> pourraient differer.) Si vous omettez les exports de OBJECT_MODE, votre compilation echouera avec des erreurs de l'editeur de liens. Lorsque OBJECT_MODE est positionne, il indique aux outils de compilation d'AIX comme << ar >>, << as >> et << ld >> quel type de fichiers a manipuler par defaut. Par defaut, de la surallocation d'espace de pagination peut se produire. Bien que nous ne l'ayons jamais constate, AIX tuera des processus quand il se trouvera a court de memoire et que la zone surallouee sera accedee. Le comportement le plus proche de ceci que nous ayons constate est l'echec d'un fork, parce que le systeme avait decide qu'il n'y avait plus de suffisamment de memoire disponible pour un nouveau processus. Comme beaucoup d'autres parties d'AIX, la methode d'allocation de l'espace de pagination et l'arret suite a un << out-of-memory >> sont configurables, soit pour le systeme, soit pour un processus, si cela devient un probleme. ------------------------------------------------------------------------ Cygwin PostgreSQL peut etre compile avec Cygwin, un environnement similaire a Linux pour Windows, mais cette methode est inferieure a la version native Windows (voir the documentation) et faire tourner un serveur sur Cygwin n'est plus recommande. Quand vous compilez a partir des sources, suivant la procedure d'installation de style Unix (c'est-a-dire ./configure; make;, etc.), notez les differences suivantes specifiques a Cygwin : - Positionnez le PATH pour utiliser le repertoire binaire Cygwin avant celui des utilitaires Windows. Cela evitera des problemes a la compilation. - La commande << adduser >> n'est pas supportee ; utilisez les outils appropries de gestion d'utilisateurs sous Windows NT, 2000 ou XP. Sinon, sautez cette etape. - La commande << su >> n'est pas supportee ; utilisez ssh pour simuler la commande << su >> sous Windows NT, 2000 ou XP. Sinon, sautez cette etape. - OpenSSL n'est pas supporte. - Demarrez << cygserver >> pour le support de la memoire partagee. Pour cela, entrez la commande /usr/sbin/cygserver &. Ce programme doit fonctionner a chaque fois que vous demarrez le serveur PostgreSQL ou que vous initialisez un cluster de bases de donnees (<< initdb >>). La configuration par defaut de << cygserver >> pourrait necessiter des changements (par exemple, augmenter SEMMNS) pour eviter a PostgreSQL d'echouer en raison d'un manque de ressources systeme. - Il se peut que la compilation echoue sur certains systemes quand une locale autre que C est utilisee. Pour resoudre ce probleme, positionnez la locale a C avec la commande << export LANG=C.utf8 >> avant de lancer la compilation, puis, une fois PostgreSQL installe, repositionnez-la a son ancienne valeur. - Les tests de regression en parallele (make check) peuvent generer des echecs de tests de regression aleatoires en raison d'un depassement de capacite de la file d'attente de listen() qui cause des erreurs de connexion refusee 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 systemes, vous pouvez avoir jusqu'a 10 connexions simultanees). 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 referer au document << README >> inclus avec le package binaire PostgreSQL sur Cygwin. Il est installe dans le repertoire << /usr/share/doc/Cygwin >>. ------------------------------------------------------------------------ macOS Sur les versions recentes de macOS, il est necessaire d'embarquer le chemin << sysroot >> dans les options d'inclusion utilisees pour trouver les fichiers d'en-tete systeme. Ceci a pour resultat la generation d'un script configure variant suivant la version du SDK utilisee durant configure. Ceci ne devrait pas poser de problemes dans les scenarios simples, mais si vous essayez de faire quelque chose comme compiler une extension sur une machine differente de celle sur laquelle le code serveur a ete compile, vous pouvez avoir besoin de forcer l'utilisation d'un chemin sysroot different. Pour cela, configurez PG_SYSROOT ainsi make PG_SYSROOT=/desired/path all Pour trouver le chemin approprie sur votre machine, lancez xcrun --show-sdk-path Notez que compiler une extension en utilisant une version sysroot differente de celle utilisee pour compiler le serveur n'est pas vraiment recommandee ; dans le pire des cas, cela peut entrainer des incoherences d'ABI difficiles a debugger. Vous pouvez aussi selectionner un chemin sysroot different de celui par defaut lors du configure en indiquant PG_SYSROOT a 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 executables qui vont en resulter fonctionneront sur l'hote actuel. Pour supprimer les options << -isysroot >>, utilisez ./configure ... PG_SYSROOT=none (tout nom de chemin non existant fonctionnera). Ceci pourrait etre utile si vous souhaitez compiler avec un compilateur autre que celui d'Apple, mais attention au fait que ce cas n'est ni teste ni supporte par les developpeurs PostgreSQL. La fonctionnalite << System Integrity Protection >> (SIP) de macOS casse make check, car elle empeche de transmettre la configuration necessaire de DYLD_LIBRARY_PATH vers les executables en cours de tests. Vous pouvez contourner cela en executant make install avant make check. Ceci etant dit, la plupart des developpeurs Postgres desactivent simplement SIP. ------------------------------------------------------------------------ MinGW/Windows Natif PostgreSQL pour Windows peut etre compile en utilisant MinGW, un environnement de compilation similaire a celui disponible sous Unix pour les systemes d'exploitation Microsoft, ou en utilisant la suite de compilation Visual C++ de Microsoft. La variante de compilation MinGW utilise le systeme de compilation normal decrit dans ce chapitre ; la compilation via Visual C++ fonctionne de facon totalement differente, et est decrite dans the documentation. Le port natif Windows requiert une version 32 ou 64 bits de Windows 2000 ou ulterieurs. Les systemes d'exploitation anterieurs n'ont pas l'infrastructure necessaire (mais Cygwin peut etre utilise pour ceux-ci). MinGW, le systeme de compilation similaire a Unix, et MSYS, une suite d'outils Unix necessaires pour executer des scripts shell tels que << configure >>, peuvent etre telecharges a partir de http://www.mingw.org/. Aucun de ces outils n'est necessaire pour executer les binaires generes ; ils ne sont necessaires que pour creer les binaires. Pour compiler les binaires 64 bits avec MinGW, installez l'ensemble d'outils 64 bits a partir de https://mingw-w64.org/, ajoutez le repertoire des binaires de MinGW dans la variable d'environnement PATH, et lancez la commande << configure >> avec l'option << --host=x86_64-w64-mingw32 >>. Apres que vous avez tout installe, il vous est conseille de lancer psql dans << CMD.EXE >>, car la console MSYS a des problemes de tampons. ------------------------------------------------------------------------ Recuperer des dumps suite aux plantages sous Windows Si PostgreSQL sous Windows plante, il peut generer des minidumps qui peuvent etre utilises pour depister 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 generation des dumps sous Windows, creez un sous-repertoire nomme << crashdumps >> dans le repertoire des donnees du cluster. Ainsi les dumps seront ecrits dans ce repertoire avec un nom unique genere a partir de l'identifiant du processus plante et du moment du plantage. ------------------------------------------------------------------------ Solaris PostgreSQL est bien supporte sous Solaris. Plus le systeme d'exploitation est a jour, moins vous aurez de problemes. ------------------------------------------------------------------------ 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 recommande sur l'architecture SPARC. Si vous utilisez le compilateur de Sun, attention a ne pas selectionner << /usr/ucb/cc >> ; utilisez << /opt/SUNWspro/bin/cc >>. Vous pouvez telecharger Sun Studio sur https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. De nombreux outils GNU sont integres dans Solaris 10, ou sont presents 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 preferez les sources, allez sur https://www.gnu.org/order/ftp.html. ------------------------------------------------------------------------ configure se plaint d'un programme de test en echec Si << configure >> se plaint d'un programme de test en echec, il s'agit probablement de l'editeur de lien a l'execution qui ne trouve pas une bibliotheque, probablement libz, libreadline ou une autre bibliotheque 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 recommande pour la compilation. Essayez d'utiliser l'option d'optimisation << -xO5 >> pour generer des binaires sensiblement plus rapides. N'utilisez pas d'options modifiant le comportement des operations a 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, preferez la version 32 bits. Les operations et les binaires 64 bits sont plus lents que les variantes 32 bits. D'un autre cote, 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'edition de liens de l'executable << postgres >> echouer avec un message d'erreur similaire a : 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 gerer les sondes dans les fonctions statiques. Solaris 10u4 ou plus recent est necessaire pour utiliser DTrace.