Installation de PostgreSQL a partir du code source ------------------------------------------------------------------------ Ce document decrit l'installation de PostgreSQL a partir de la presente distribution du code source. ------------------------------------------------------------------------ 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/postgres -D /usr/local/pgsql/data >logfile 2>&1 & /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 style unix modernes sont capables d'executer PostgreSQL. Les plateformes sur lesquelles des tests ont ete effectues sont listees dans la la section intitulee << Plateformes supportees >> ci-apres. Dans le repertoire << doc >> de la distribution, il y a plusieurs FAQ specifiques a des plateformes particulieres a consulter en cas de difficultes. 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 C89). Une version recente de GCC est recommandee, mais PostgreSQL est connu pour etre compilable avec de nombreux compilateurs de divers 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 touches de fleches pour rappeler et editer les commandes precedentes. C'est tres pratique et fortement recommande. Pour ne pas l'utiliser, il faut preciser << --without-readline >> au moment de l'execution de la commande << configure >>. Une alternative possible est l'utilisation de la bibliotheque << libedit >> sous licence BSD, developpee au debut sur NetBSD. La bibliotheque << libedit >> est compatible GNU Readline et est utilisee si cette derniere n'est pas trouvee ou si << --with-libedit-preferred >> est utilise sur la ligne de commande de << configure >>. Lorsqu'une distribution Linux a base de paquets est utilisee, si les paquets readline et readline-devel sont separes, il faut imperativement installer les deux. - La bibliotheque de compression zlib est utilisee par defaut. Pour ne pas l'utiliser, 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 installer 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 n'etait pas le cas dans les versions plus anciennes. Dans tous les cas, c'est du ressort de celui qui installe Perl. << configure >> echouera si la construction de PL/Perl est selectionnee mais qu'il ne trouve pas une bibliotheque partagee << libperl >>. Dans ce cas, vous devrez reconstruire et installer Perl manuellement pour etre capable de construire 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 construits a partir des sources mais, une bibliotheque partagee est disponible dans de nombreuses distributions de systemes d'exploitation. << configure >> echouera si la construction de PL/Python est selectionnee et qu'il ne peut pas trouver une bibliotheque partagee << libpython >>. Cela pourrait signifier que vous avez soit besoin d'installer des packages supplementaires soit reconstruire (une partie de) l'installation Python pour fournir cette bibliotheque partagee. Lors de la construction a partir des sources, executez le configure de Python avec l'option --enable-shared. - Pour construire le langage procedural PL/Tcl, Tcl doit etre installe. La version minimale requise de Tcl est la 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 implantation de l'API Gettext est necessaire. Certains systemes d'exploitation l'integrent (par exemple, Linux, NetBSD, Solaris). Pour les autres systemes, un paquet additionnel peut etre telecharge sur http://www.gnu.org/software/gettext/. Pour utiliser l'implantation Gettext des bibliotheques C GNU, certains utilitaires necessitent le paquet GNU Gettext. Il n'est pas necessaire dans les autres implantations. - Vous aurez besoin de OpenSSL, si vous voulez utiliser du chiffrement pour vos connexions clientes. La version minimale requise est la 0.9.8. - Vous avez besoin de Kerberos, OpenLDAP ou PAM pour beneficier de l'authentification ou du chiffrement en utilisant ces services. - Pour construire la documentation PostgreSQL, il existe un ensemble de prerequis separe ; voir the main documentation's appendix on documentation. En cas de compilation a partir d'une arborescence Git et non d'un paquet de 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 lorsque les fichiers de definition de l'analyseur ou du << scanner >> sont modifies. Les versions necessaires sont Flex 2.5.31 ou ulterieure et Bison 1.875 ou ulterieure. Les autres programmes lex et yacc ne peuvent pas etre utilises. - Perl 5.8.3 ou ulterieur est aussi necessaire pour construire les sources du Git, ou lorsque les fichiers en entree pour n'importe laquelle des etapes de construction qui utilisent des scripts Perl ont ete modifies. Sous Windows, Perl est necessaire dans tous les cas. Perl est aussi requis pour executer certains tests unitaires. Si d'autres paquets GNU sont necessaires, ils peuvent etre recuperes sur un site miroir 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. 100 Mo sont necessaires pour la compilation et 20 Mo pour le repertoire d'installation. Un groupe de bases de donnees vide necessite 35 Mo ; les fichiers des bases prennent cinq fois plus d'espace que des fichiers texte contenant les memes donnees. Si des tests de regression sont prevus, 150 Mo supplementaires sont temporairement necessaires. On peut utiliser 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 interessantes. Ce qui est 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 certains aleas relatifs au systeme d'exploitation. Il creera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a ete trouve. << configure >> peut aussi etre execute a partir d'un repertoire hors de l'arborescence des sources pour conserver l'arborescence de compilation separee. Cette procedure est aussi appelee une construction de type VPATH. Voici comment la faire : mkdir build_dir cd build_dir /path/to/source/tree/configure [les options vont ici] make La configuration par defaut compilera le serveur et les utilitaires, aussi bien que toutes les applications clientes et interfaces qui requierent seulement un compilateur C. Tous les fichiers seront installes par defaut sous << /usr/local/pgsql >>. Les processus de compilation et d'installation peuvent etre personnalises par l'utilisation d'une ou plusieurs options sur la ligne de commande apres << configure >> : --prefix=PREFIX Installe tous les fichiers dans le repertoire << PREFIX >> au lieu du repertoire << /usr/local/pgsql >>. Les fichiers actuels seront installes dans divers sous-repertoires ; aucun fichier ne sera directement installe sous << PREFIX >>. Pour satisfaire des besoins specifiques, les sous-repertoires peuvent etre personnalises a l'aide des options qui suivent. Toutefois, en laissant les options par defaut, l'installation est deplacable, ce qui signifie que le repertoire peut etre deplace apres installation. (Cela n'affecte pas les emplacements de man et doc.) Pour les installations deplacables, on peut utiliser l'option --disable-rpath de << configure >>. De plus, il faut indiquer au systeme d'exploitation comment trouver les bibliotheques partagees. --exec-prefix=EXEC-PREFIX Les fichiers qui dependent de l'architecture peuvent etre installes dans un repertoire different, << EXEC-PREFIX >>, de celui donne par << PREFIX >>. Cela peut etre utile pour partager les fichiers independant de l'architecture entre plusieurs machines. 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 Precise 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, il s'agit de << 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 en-tetes 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 >>. 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 locales, en particulier les fichiers catalogues de traductions de messages. La valeur par defaut est << DATAROOTDIR/locale >>. --mandir=REPERTOIRE Les pages man 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 formatee en HTML pour PostgreSQL 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 des noms de fichiers relatifs au 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 il sera dans << /opt/postgres/doc >>. Les fichiers d'en-tete publiques C de l'interface cliente seront installes sous includedir et sont independants des noms de fichiers relatifs au reste du systeme. Les fichiers d'en-tete prives et les fichiers d'en-tete 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, un repertoire prive sera aussi cree si necessaire sous libdir pour les modules chargeables dynamiquement. --with-extra-version=STRING Ajoute << STRING >> au numero de version de PostgreSQL. Cela peut etre utilise, par exemple, pour marquer des binaires compiles depuis des instantanes Git ne faisant pas encore partie d'une version officielle ou contenant des patchs particuliers avec une chaine de texte supplementaire telle qu'un identifiant << git describe >> ou un numero de version d'un paquet d'une distribution. --with-includes=REPERTOIRES << REPERTOIRES >> est une liste de repertoires separes par le caractere deux points (:) qui sera ajoutee a la liste de recherche des fichiers d'en-tete du compilateur. Si vous avez des paquetages optionnels (tels que Readline GNU) installes dans des repertoires non conventionnels, vous devez utiliser cette option et probablement aussi l'option << --with-libraries >> correspondante. Exemple : --with-includes=/opt/gnu/include:/usr/sup/include. --with-libraries=REPERTOIRES << REPERTOIRES >> est une liste de recherche de repertoires de bibliotheques separes par le caractere deux points (:). Si des paquets sont installes dans des repertoires non conventionnels, il peut s'averer necessaire d'utiliser cette option (ainsi que l'option correspondante << --with-includes >>). Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib. --enable-nls[=LANGUES] Permet de mettre en place le support des langues natives (NLS). C'est la 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 un 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 implantation de l'API Gettext est necessaire ; voir ci-dessous. --with-pgport=NUMERO Positionne << NUMERO >> comme numero de port par defaut pour le serveur et les clients. La valeur par defaut est 5432. Le port peut toujours etre modifie ulterieurement mais, s'il est precise ici, les executables du serveur et des clients auront la meme valeur par defaut, ce qui est vraiment tres pratique. Habituellement, la seule bonne raison de choisir une autre valeur que celle par defaut est l'execution de plusieurs serveurs PostgreSQL sur la meme machine. --with-perl Permet l'utilisation du langage de procedures PL/Perl cote serveur. --with-python Permet la compilation du langage de procedures PL/Python. --with-tcl Permet la compilation du langage de procedures PL/Tcl. --with-tclconfig=REPERTOIRE Tcl installe les fichiers << tclConfig.sh >>, contenant certaines informations de configuration necessaires pour compiler le module d'interfacage avec Tcl. Ce fichier est trouve automatiquement mais pour utiliser une version differente de Tcl, il faut indiquer le repertoire dans lequel il se trouve. --with-gssapi Permet la compilation avec le support de l'authentification GSSAPI. Sur de nombreux systemes, GSSAPI (qui fait habituellement partie d'une installation Kerberos) n'est pas installe dans un emplacement recherche par defaut (c'est-a-dire << /usr/include >>, << /usr/lib >>), donc vous devez utiliser les options << --with-includes >> et << --with-libraries >> en plus de cette option. << configure >> verifiera les fichiers d'en-tete et les bibliotheques necessaires pour s'assurer que votre installation GSSAPI est suffisante avant de continuer. --with-krb-srvnam=NOM Le nom par defaut du service principal de Kerberos utilise. postgres est pris par defaut. Il n'y a habituellement pas de raison de le changer sauf dans le cas d'un environnement Windows, auquel cas il doit etre mis en majuscule, POSTGRES. --with-llvm Permet la compilation avec le support de JIT basee sur LLVM. Ceci necessite l'installation de la bibliotheque LLVM. La version minimale requise de LLVM est actuellement la 3.9. << llvm-config >> sera utilise pour trouver les options de compilation requises. << llvm-config >>, puis << llvm-config-$major-$minor >> pour toutes les versions supportees, seront recherche dans PATH. Dans le cas ou les bons binaires ne sont pas trouves, il faut utiliser la variable LLVM_CONFIG afin de specifier le chemin a << llvm-config >>. Par exemple : ./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config' Le support de LLVM necessite un compilateur << clang >> compatible (qui peut etre specifie, si necessaire, en utilisant la variable d'environnement CLANG, et un compilateur C++ fonctionnel (qui peut etre specifie, si necessaire, en utilisant la variable d'environnement CXX). --with-icu Installer PostgreSQL avec la bibliotheque ICU L'installation des paquets ICU4C et pkg-config sont un pre-requis. La version minimale requise de ICU4C est actuellement la 4.2. Par defaut, pkg-config sera utilise pour trouver les options requises de compilation. C'est supporte par les versions 4.6 et ulterieures de ICU4C. Pour les versions plus anciennes ou si pkg-config n'est pas disponible, les variables ICU_CFLAGS et ICU_LIBS peuvent etre donnees 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 de recherche par defaut du compilateur, alors vous aurez besoin d'indiquer une chaine non vide pour eviter l'utilisation de pkg- config, par exemple ICU_CFLAGS=' '.) --with-openssl Compile le support de connexion SSL (chiffrement). Le paquetage OpenSSL doit etre installe. << configure >> verifiera que les fichiers d'en-tete et les bibliotheques soient installes pour s'assurer que votre installation d'OpenSSL est suffisante avant de continuer. --with-pam Compile le support PAM (Modules d'Authentification Pluggable). --with-bsd-auth Compile le support de l'authentification BSD (l'environnement d'authentification BSD est uniquement disponible sur OpenBSD actuellement.) --with-ldap Demande l'ajout du support de LDAP pour l'authentification et la recherche des 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 requis pour s'assurer que votre installation d'OpenLDAP est suffisante avant de continuer. --with-systemd Compile le support des notifications du service systemd . Ceci ameliore l'integration si le binaire du serveur est lance par systemd mais n'a pas d'impact dans le cas contraire. libsystemd et les fichiers en-tetes associes doivent etre installes pour pouvoir utiliser cette option. --without-readline Evite l'utilisation de la bibliotheque Readline (et de celle de libedit). Cela desactive l'edition de la ligne de commande et l'historique dans psql, ce n'est donc pas recommande. --with-libedit-preferred Favorise l'utilisation de la bibliotheque libedit (sous licence BSD) plutot que Readline (GPL). Cette option a seulement un sens si vous avez installe les deux bibliotheques ; dans ce cas, par defaut, Readline est utilise. --with-bonjour Compile le support de Bonjour. Ceci requiert le support de Bonjour dans votre systeme d'exploitation. Recommande sur macOS. --with-uuid=LIBRARY Compile le module uuid-ossp (qui fournit les fonctions pour generer les UUID), en utilisant la bibliotheque UUID specifiee. << LIBRARY >> doit correspondre a une de ces valeurs : - << bsd >> pour utiliser les fonctions UUID trouvees dans FreeBSD et quelques 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 obtenu sur d'autres plateformes egalement - << ossp >> pour utiliser la bibliotheque OSSP UUID --with-ossp-uuid Equivalent obsolete de --with-uuid=ossp. --with-libxml Construit 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 se trouvant 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 soit configurer XML2_CONFIG soit XML2_CFLAGS et XML2_LIBS avec des chaines non vides.) --with-libxslt Utilise libxslt pour construire le module xml2. Le module << contrib/xml2 >> se base sur cette bibliotheque pour realiser les transformations XSL du XML. --disable-float4-byval Desactive le passage << par valeur >> des valeurs float4, entrainant leur passage << par reference >> a la place. Cette option a un cout en performance, mais peut etre necessaire pour maintenir la compatibilite avec des anciennes fonctions creees par l'utilisateur qui sont ecrites en C et utilisent la convention d'appel << version 0 >>. Une meilleure solution a long terme est de mettre a jour toutes ces fonctions pour utiliser la convention d'appel << version 1 >>. --disable-float8-byval Desactive le passage << par valeur >> des valeurs float8, entrainant leur passage << par reference >> a la place. Cette option a un cout en performance, mais peut etre necessaire pour maintenir la compatibilite avec des anciennes fonctions creees par l'utilisateur qui sont ecrites en C et utilisent la convention d'appel << version 0 >>. Une meilleure solution a long terme est de mettre a jour toutes ces fonctions pour utiliser la convention d'appel << version 1 >>. Notez que cette option n'affecte pas que float8, mais aussi int8 et quelques types apparentes comme timestamp. Sur les plateformes 32 bits, << --disable-float8-byval >> est la valeur par defaut, et il n'est pas permis de selectionner << --enable-float8-byval >>. --with-segsize=TAILLESEG Indique la taille d'un segment, en gigaoctets. La valeur par defaut est de 1 gigaoctet, valeur consideree comme sure pour toutes les plateformes prises en charge. Les grandes tables sont divisees en plusieurs fichiers du systeme d'exploitation, chacun de taille egale a la taille de segment. Cela evite les problemes avec les limites de tailles de fichiers qui existent sur de nombreuses plateformes. Si votre systeme d'exploitation supporte les fichiers de grande taille (<< largefile >>), ce qui est le cas de la plupart d'entre eux de nos jours, vous pouvez utiliser une plus grande taille de segment. Cela peut etre utile pour reduire le nombre de descripteurs de fichiers qui peuvent etre utilises lors de travail sur des tres grandes tables. Attention a ne pas selectionner une valeur plus grande que ce qui est supporte par votre plateforme et le(s) systeme(s) de fichiers que vous prevoyez d'utiliser. D'autres outils que vous pourriez vouloir utiliser, tels que tar, pourraient aussi limiter la taille maximum utilisable pour un fichier. Il est recommande, meme si pas vraiment necessaire, que cette valeur soit une puissance de 2. Notez que changer cette valeur impose de faire un initdb. --with-blocksize=TAILLEBLOC Indique la taille d'un bloc, en kilooctets. C'est l'unite de stockage et d'entree/sortie dans les tables. La valeur par defaut, 8 kilooctets, est appropriee pour la plupart des cas ; mais d'autres valeurs peuvent etre utilisees dans des cas particuliers. Cette valeur doit etre une puissance de 2 entre 1 et 32 (kilooctets). Notez que changer cette valeur impose de faire un initdb. --with-wal-blocksize=TAILLEBLOC Indique la taille d'un bloc WAL, en kilooctets. C'est l'unite de stockage et d'entree/sortie dans le journal des transactions. La valeur par defaut, 8 kilooctets, est appropriee pour la plupart des cas ; mais d'autres valeurs peuvent etre utilises dans des cas particuliers. La valeur doit etre une puissance de 2 comprise entre 1 et 64 (kilooctets). --disable-spinlocks Autorise le succes de la construction y compris lorsque PostgreSQL n'a pas le support spinlock du CPU pour la plateforme. Ce manque de support resultera en des performances faibles ; du coup, cette option devra seulement etre utilisee si la construction echoue et vous informe du manque de support de spinlock sur votre plateforme. Si cette option est requise pour construire PostgreSQL sur votre plateforme, merci de rapporter le probleme aux developpeurs de PostgreSQL. --disable-strong-random Autorise le succes de la construction y compris lorsque PostgreSQL n'a pas le support pour les nombres aleatoires forts sur la plateforme. Une source de nombres aleatoires est necessaire pour certains protocoles d'authentification, de meme que certaines procedures du module pgcrypto. Le parametre << --disable-strong-random >> desactive toutes les fonctionnalites qui necessitent des nombres aleatoires forts pour la cryptographie et y substitue un generateur fragile de nombres pseudo aleatoires pour generer les valeurs pour l'authentification salee et les cles d'annulation de requetes. Cela rend l'authentification moins securisee. --disable-thread-safety Desactive la securite des threads pour les bibliotheques clients. Ceci empeche les threads concurrents dans les programmes libpq et ECPG de controler en toute securite leurs pointeurs de connexion prives. --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 ce serait 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 tres probable 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 vous 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 a pour cible les distributeurs de paquets binaires qui connaissent leur systeme d'exploitation. Le principal avantage d'utiliser cette option est que le package PostgreSQL n'aura pas besoin d'etre mis a jour a chaque fois que les regles des fuseaux horaires changent. 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. --without-zlib Evite l'utilisation de la bibliotheque Zlib. Cela desactive le support des archives compressees dans pg_dump et pg_restore. Cette option est seulement la pour les rares systemes qui ne disposent pas de cette bibliotheque. --enable-debug Compile tous les programmes et bibliotheques en mode de debogage. Cela signifie que vous pouvez executer les programmes via un debogueur pour analyser les problemes. Cela grossit considerablement la taille des executables et, avec des compilateurs autres que GCC, habituellement, cela desactive les optimisations du compilateur, provoquant des ralentissements. Cependant, mettre ce mode en place est extremement utile pour reperer les problemes. Actuellement, cette option est recommandee pour les installations en production seulement si vous utilisez GCC. Neanmoins, vous devriez l'utiliser si vous developpez ou si vous utilisez une version beta. --enable-coverage Si vous utilisez GCC, 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 uniquement en phase de developpement. --enable-profiling En cas d'utilisation de GCC, tous les programmes et bibliotheques sont compiles pour qu'elles puissent etre profilees. A la sortie du processus serveur, un sous-repertoire sera cree pour contenir le fichier << gmon.out >> a utiliser pour le profilage. Cette option est a utiliser uniquement avec GCC lors d'un developpement. --enable-cassert Permet la verification des assertions par le serveur qui teste de nombreux cas de conditions << impossibles >>. Ce qui est inestimable dans le cas de developpement, mais les tests peuvent ralentir sensiblement le systeme. Activer cette option n'influe pas sur la stabilite de votre serveur ! Les assertions verifiees ne sont pas classees par ordre de severite et il se peut qu'un bogue anodin fasse redemarrer le serveur s'il y a un echec de verification. Cette option n'est pas recommandee dans un environnement de production mais vous devriez l'utiliser lors de developpement ou pour les versions beta. --enable-depend Active la recherche automatique des dependances. Avec cette option, les fichiers makefile sont appeles pour recompiler les fichiers objet des qu'un fichier d'en-tete est modifie. C'est pratique si vous faites du developpement, mais inutile si vous ne voulez que compiler une fois et installer. Pour le moment, cette option ne fonctionne qu'avec GCC. --enable-dtrace Compile PostgreSQL avec le support de l'outil de trace dynamique, DTrace. Voir the documentation pour plus d'informations. Pour pointer vers le programme << dtrace >>, la variable d'environnement DTRACE doit etre configuree. Ceci sera souvent necessaire car << dtrace >> est typiquement installe sous << /usr/sbin >>, qui pourrait ne pas etre dans le chemin. Des options supplementaires en ligne de commande 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-bit, ajoutez l'option DTRACEFLAGS="-64" pour configure. Par exemple, en utilisant le compilateur GCC : ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ... En utilisant le compilateur de Sun : ./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ... --enable-tap-tests Active les tests utilisant les outils TAP de Perl. Cela necessite une installation de Perl et de son module IPC::Run. 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 CLANG chemin vers le programme << clang >> utilise pour l'optimisation inline du code source lors de la compilation avec --with-llvm CPP preprocesseur C CPPFLAGS options a passer au preprocesseur C CXX C++ compiler CXXFLAGS options to pass to the C++ compiler 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 << llvm-config >> program used to locate the LLVM installation. MSGFMT programme << msgfmt >> pour le support des langues PERL programme interpreteur Perl. Il sera utilise pour determiner les dependances pour la construction 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 construction 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 construction de PL/Perl. PYTHON programme interpreteur Python. Il sera utilise pour determiner les dependances pour la construction 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 cette variable n'est pas configuree, les suivantes sont testees dans cet ordre : python python3 python2. TCLSH programme interpreteur Tcl. Il sera utilise pour determiner les dependances pour la construction de PL/Tcl, et il sera substitue dans des scripts Tcl. XML2_CONFIG programme << xml2-config >> utilise pour localiser l'installation de libxml2. Il est parfois utile d'ajouter des options de compilation a l'ensemble choisi par << configure >> apres coup. Un exemple parlant concerne l'option << -Werror >> de gcc qui ne peut pas etre incluse dans la variable CFLAGS passee a << configure >>, car il cassera un grand nombre de tests internes de << configure >>. Pour ajouter de telles options, incluez- les dans la variable d'environnement COPT lors de l'execution de << gmake >>. Le contenu de COPT est ajoute aux variables CFLAGS et LDFLAGS configurees par << configure >>. Par exemple, vous pouvez faire : gmake COPT='-Werror' ou export COPT='-Werror' gmake Note: Lors de l'ecriture de code a l'interieur du serveur, il est recommande d'utiliser les options << --enable-cassert >> (qui active un grand nombre de verifications d'erreur a l'execution) et << --enable-debug >> (qui ameliore l'utilite des outils de debogage) de configure. Si vous utilisez GCC, il est preferable de construire avec un niveau d'optimisation d'au moins << -O1 >> parce que desactiver toute optimisation (<< -O0 >>) desactive aussi certains messages importants du compilateur (comme l'utilisation de variables non initialisees). Neanmoins, les niveaux d'optimisations peuvent compliquer le debuggage parce que faire du pas-a-pas sur le code compile ne correspondra pas forcement aux lignes de code une-a-une. Si vous avez du mal a debugger du code optimise, recompilez les fichiers interessants avec << -O0 >>. Une facon simple de le faire est de passer une option a make: << make PROFILE=-O0 file.o >>. Les variables d'environnement COPT et PROFILE sont gerees de facon identique par les fichiers makefile de PostgreSQL. Laquelle utiliser est une affaire de preference, mais un usage commun parmi les developpeurs est d'utiliser PROFILE pour les ajustements inhabituels alors que COPT servirait aux variables a configurer a chaque fois. 2. Compilation Pour demarrer la compilation, saisissez soit make make all (Rappelez-vous d'utiliser GNU make). La compilation prendra quelques minutes, selon votre materiel. La derniere ligne affichee devrait etre All of PostgreSQL successfully made. Ready to install. Si vous voulez lancer la construction a partir d'un autre fichier makefile, vous devez configurer MAKELEVEL ou l'initialiser a zero, par exemple ainsi : build-postgresql: $(MAKE) -C postgresql MAKELEVEL=0 all Ne pas le faire amene des messages d'erreur etranges, typiquement sur des fichiers d'en-tete manquants. Si vous voulez construire tout ce qui peut etre construit, ceci incluant la documentation (HTML et pages man) et les modules supplementaires (<< contrib >>), saisissez a la place : 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 3. Tests de regression Si vous souhaitez tester le serveur nouvellement compile avant de l'installer, vous pouvez executer les tests de regression a ce moment. Les tests de regression sont une suite de tests qui verifient que PostgreSQL fonctionne sur votre machine tel que les developpeurs l'esperent. Saisissez make check (cela ne fonctionne pas en tant que root ; faites-le en tant qu'utilisateur sans droits). Le the file << src/test/regress/README >> and the documentation contient des details sur l'interpretation des resultats de ces tests. Vous pouvez les repeter autant de fois que vous le voulez en utilisant la meme commande. 4. Installer les fichiers Note: Si vous mettez a jour une version existante, assurez-vous d'avoir bien lu the documentation qui donne les instructions sur la mise a jour d'un cluster. Pour installer PostgreSQL, saisissez make install Cela installera les fichiers dans les repertoires specifies dans l'Etape 1. Assurez-vous d'avoir les droits appropries pour ecrire dans ces repertoires. Normalement, vous avez besoin d'etre superutilisateur pour cette etape. Une alternative consiste a creer les repertoires cibles a l'avance et a leur donner les droits appropries. Pour installer la documentation (HTML et pages man), saisissez : make install-docs Si vous construisez tout, saisissez ceci a la place : make install-world Cela installe aussi la documentation. Si vous voulez tout construire, sauf la documentation, saisissez a la place : make install-world-bin Vous pouvez utiliser make install-strip en lieu et place de make install pour depouiller l'installation des executables et des bibliotheques. Cela economise un peu d'espace disque. Si vous avez effectue la compilation en mode de debogage, ce depouillage l'enlevera, donc ce n'est a faire seulement si ce mode n'est plus necessaire. install-strip essaie d'etre raisonnable en sauvegardant de l'espace disque mais il n'a pas une connaissance parfaite de la facon de depouiller un executable de tous les octets inutiles. Ainsi, si vous voulez sauvegarder le maximum d'espace disque, vous devrez faire le travail a la main. L'installation standard fournit seulement les fichiers en-tetes necessaires pour le developpement d'applications clientes ainsi que pour le developpement de programmes cote serveur comme des fonctions personnelles ou des types de donnees ecrits en C (avant PostgreSQL 8.0, une commande make install-all-headers separee etait necessaire pour ce dernier point, mais cette etape a ete integree a l'installation standard). Installation du client uniquement : Si vous voulez uniquement installer les applications clientes et les bibliotheques d'interface, alors vous pouvez utilisez ces commandes : make -C src/bin install make -C src/include install make -C src/interfaces install make -C doc install << src/bin >> comprend quelques executables utilises seulement par le serveur mais ils sont petits. Desinstallation : Pour desinstaller, utilisez la commande << make uninstall >>. Cependant, cela ne supprimera pas les repertoires crees. Nettoyage : Apres l'installation, vous pouvez liberer de l'espace en supprimant les fichiers issus de la compilation des repertoires sources a l'aide de la commande << make clean >>. Cela conservera les fichiers crees par la commande << configure >>, ainsi vous pourrez tout recompiler ulterieurement avec << make >>. Pour remettre l'arborescence source dans l'etat initial, utilisez << make distclean >>. Si vous voulez effectuer la compilation pour diverses plateformes a partir des memes sources vous devrez d'abord refaire la configuration a chaque fois (autrement, utilisez un repertoire de construction separe pour chaque plateforme, de facon a ce que le repertoire des sources reste inchange). Si vous avez compile et que vous vous etes rendu compte que les options de << configure >> sont fausses ou si vous changez quoi que ce soit que << configure >> prenne en compte (par exemple, la mise a jour d'applications), alors faire un << make distclean >> avant de reconfigurer et recompiler est une bonne idee. Sans ca, vos changements dans la configuration ne seront pas repercutes partout ou il faut. ------------------------------------------------------------------------ Initialisation post-installation ------------------------------------------------------------------------ Bibliotheques partagees Sur certains systemes qui utilisent les bibliotheques partagees (ce que font de nombreux systemes), vous avez besoin de leurs 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 methode la plus repandue consiste a positionner des variables d'environnement comme LD_LIBRARY_PATH : 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 >>. Certaines informations pertinentes au sujet de mises en garde associees a cette methode peuvent etre trouvees 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. Faites-y attention. 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 endroit qui n'est pas dans les repertoires contenant les executables par defaut, vous devez ajouter << /usr/local/pgsql/bin >> (ou le repertoire fourni a << --bindir >> au moment de l'Etape 1) dans votre PATH. Techniquement, 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, par exemple << ~/.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 mises 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 c'est plus pratique si tous les utilisateurs peuvent parametrer 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/postgres -D /usr/local/pgsql/data Cela demarrera le serveur en avant-plan. Pour envoyer le serveur en arriere-plan, utilisez quelque chose comme : nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \ >server.log 2>&1 >, 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 supportee par la communaute de developpeur de PostgreSQL si le code permet le fonctionnement sur cette plateforme et que la construction et les tests de regression ont ete recemment verifies sur cette plateforme. Actuellement, la plupart des tests de compatibilite de plateforme se font automatiquement par des machines de tests dans la ferme de construction de PostgreSQL. Si vous etes interesses par l'utilisation de PostgreSQL sur une plateforme qui n'est pas representee dans la ferme de construction, mais pour laquelle le code fonctionne ou peut fonctionner, nous vous suggerons fortement de construire 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 construire PostgreSQL sur un type de processeur non supporte en precisant << --disable-spinlocks >>. Cependant, les performances en souffriront. PostgreSQL doit fonctionner sur les systemes d'exploitation suivants : Linux (toutes les distributions recentes), Windows (Win2000 SP4 et ulterieures), FreeBSD, OpenBSD, NetBSD, macOS, AIX, HP/UX et Solaris. D'autres systemes style Unix peuvent aussi fonctionner mais n'ont pas ete recemment testes. 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 vieux systeme. Si vous avez des problemes d'installation sur une plateforme qui est connue comme etant supportee d'apres les recents resultats de la ferme de construction, 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 PostgreSQL fonctionne sur AIX, mais reussir a l'installer correctement peut s'averer difficile. Les versions AIX de la 4.3.3 a la 6.1 sont considerees comme supportees en theorie. Vous pouvez utiliser GCC ou le compilateur natif IBM << xlc >>. En general, utiliser des versions recentes d'AIX et PostgreSQL rend la tache plus simple. Verifiez la ferme de compilation pour avoir des informations a jour sur les versions d'AIX connues pour etre compatibles. Les niveaux minimums recommandes de correctifs pour les versions supportees de AIX sont : AIX 4.3.3 Maintenance Level 11 + post ML11 bundle AIX 5.1 Maintenance Level 9 + post ML9 bundle AIX 5.2 Technology Level 10 Service Pack 3 AIX 5.3 Technology Level 7 AIX 6.1 Base Level Pour verifier votre niveau de correctif, utilisez << oslevel -r >> de AIX 4.3.3 a AIX 5.2 ML 7, et << oslevel -s >> pour les versions ulterieures. Utilisez les options de << configure >> en plus de vos propres options si vous avez installe Readline ou libz dans /usr/local : --with-includes=/usr/local/include --with-libraries=/usr/local/lib. ------------------------------------------------------------------------ Problemes avec GCC Sur AIX 5.3, il y a des problemes pour compiler et faire fonctionner PostgreSQL avec GCC. Vous voudrez utiliser une version de GCC superieure a 3.3.2, en particulier si vous utilisez une version pre-packagee. Nous avons eu de bons resultats avec la 4.0.1. Les problemes avec les versions precedentes semblent etre davantage lies a la facon dont IBM a package GCC qu'a des problemes reels, avec GCC, ce qui fait que si vous compilez GCC vous-meme, vous pourriez reussir avec une version plus ancienne de GCC. ------------------------------------------------------------------------ Sockets du domaine Unix inutilisables Dans AIX 5.3, la structure sockaddr_storage n'est pas definie avec une taille suffisante. En version 5.3, IBM a augmente la taille de sockaddr_un, la structure d'adresse pour une socket de domaine Unix, mais n'a pas augmente en consequence la taille de sockaddr_storage. La consequence est que les tentatives d'utiliser une socket de domaine Unix avec PostgreSQL amenent libpq a depasser la taille de la structure de donnees. Les connexions TCP/IP fonctionnent, mais pas les sockets de domaine Unix, ce qui empeche les tests de regression de fonctionner. Le probleme a ete rapporte a IBM, et est enregistre en tant que rapport de bogue PMR29657. Si vous mettez a jour vers le niveau de maintenance 5300-03 et ulterieur, le correctif sera inclus. Une resolution immediate est de corriger _SS_MAXSIZE a 1025 dans << /usr/include/sys/socket.h >>. Dans tous les cas, recompilez PostgreSQL une fois que vous avez l'en-tete corrige. ------------------------------------------------------------------------ Problemes avec les adresses internet PostgreSQL se base sur la fonction systeme getaddrinfo pour analyser les adresses IP dans listen_addresses et dans << pg_hba.conf >>, etc. Les anciennes versions d'AIX ont quelques bogues dans cette fonction. Si vous avez des problemes relatifs a ces parametres, la mise a jour vers le niveau de correctif AIX approprie indique ci-dessus devrait resoudre cela. Un utilisateur a rapporte : Lors de l'implementation de PostgreSQL version 8.1 sur AIX 5.3, nous tombions periodiquement sur des problemes quand le collecteur de statistiques ne voulait << mysterieusement >> pas demarrer. Cela se trouvait etre le resultat d'un comportement inattendu dans l'implementation d'IPv6. Il semble que PostgreSQL et IPv6 ne fonctionnent pas bien ensemble sur AIX 5.3. Chacune des actions suivantes << corrige >> le probleme. - Supprimer l'adresse IPv6 pour localhost : (as root) # ifconfig lo0 inet6 ::1/0 delete - Supprimer IPv6 des services reseau. Le fichier << /etc/netsvc.conf >> sur AIX est en gros equivalent a << /etc/nsswitch.conf >> sur Solaris/Linux. La valeur par defaut, sur AIX, est donc : hosts=local,bind Remplacez ceci avec : hosts=local4,bind4 pour desactiver la recherche des adresses IPv6. Avertissement: Ceci est en realite un contournement des problemes relatifs a l'immaturite du support IPv6, qui a ameliore la visibilite pour les versions 5.3 d'AIX. Cela a fonctionne avec les versions 5.3 d'AIX mais n'en fait pas pour autant une solution elegante a ce probleme. Certaines personnes ont indique que ce contournement est non seulement inutile, mais pose aussi des problemes sur AIX 6.1, ou le support IPv6 est beaucoup plus mature. ------------------------------------------------------------------------ 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 32-bits et installes en mode 750 au lieu de 755. En raison des droits, seul le proprietaire ou un membre du groupe proprietaire peut charger la bibliotheque. Puisqu'il n'est pas lisible par tout le mode, 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 >> pour ceci 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 ne peuvent pas executer de 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 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 le << out-of-memory kill >> sont configurables soit pour le systeme soit pour un processus, si cela devient un probleme. ------------------------------------------------------------------------ Cygwin PostgreSQL peut etre construit 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 normale d'installation (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 permettra d'eviter des problemes avec 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 construction echoue sur certains systeme 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 construction, et ensuite, une fois que vous avez installe PostgreSQL, 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 >>. ------------------------------------------------------------------------ HP-UX PostgreSQL 7.3 et plus devraient fonctionner sur les machines PA-RISC Series 700/800 sous HP-UX 10.X ou 11.X, si les correctifs appropries sur le systeme et les outils de compilation sont bien appliques. Au moins un developpeur teste de facon reguliere sur HP-UX 10.20, et nous avons des rapports d'installations reussies sur HP-UX 11.00 et 11.11. En plus de la distribution source de PostgreSQL, vous aurez besoin de GNU make (le make HP ne fonctionnera pas) et soit GCC soit le compilateur ANSI HP. Si vous avez l'intention de compiler a partir des sources Git plutot que d'une distribution tar, vous aurez aussi besoin de Flex (les GNU) et Bison (yacc GNU). Nous vous recommandons aussi de vous assurer que vous etes assez a jour sur les correctifs HP. Au minimum, si vous compilez des binaires 64 bits sur HP-UX 11.11, vous aurez probablement besoin de PHSS_30966 (11.11) ou d'un correctif superieur, sinon << initdb >> pourrait bloquer : PHSS_30966 s700_800 ld(1) and linker tools cumulative patch De facon generale, vous devriez etre a jour sur les correctifs libc et ld/dld, ainsi que sur les correctifs du compilateur si vous utilisez le compilateur C de HP. Voir les sites de support HP comme ftp://us-ffs.external.hp.com/ pour telecharger gratuitement leurs derniers correctifs. Si vous compilez sur une machine PA-RISC 2.0 et que vous voulez avoir des binaires 64 bits en utilisant GCC, vous devez utiliser la version 64 bits de GCC. Si vous compilez sur une machine PA-RISC 2.0 et que vous voulez que les binaires compiles fonctionnent sur une machine PA-RISC 1.1, vous devez specifier << +DAportable >> comme CFLAGS. Si vous compilez sur une machine HP-UX Itanium, vous aurez besoin du dernier compilateur C ANSI HP avec les correctifs qui en dependent : PHSS_30848 s700_800 HP C Compiler (A.05.57) PHSS_30849 s700_800 u2comp/be/plugin library Patch Si vous avez a la fois le compilateur C HP et celui de GCC, vous voudrez peut etre specifier explicitement le compilateur a utiliser quand vous executerez << configure >> : ./configure CC=cc pour le compilateur HP, ou ./configure CC=gcc pour GCC. Si vous omettez ce parametre, configure choisira << gcc >> s'il en a la possibilite. Le repertoire par defaut d'installation est << /usr/local/pgsql >>, que vous voudrez peut etre remplacer par quelque chose dans << /opt >>. Si c'est le cas, utilisez l'option << --prefix >> de << configure >>. Dans les tests de regression, il pourrait y avoir des differences dans les chiffres les moins significatifs des tests de geometrie, qui varient suivant les versions de compilateur et de bibliotheque mathematique utilisees. Toute autre erreur est suspecte. ------------------------------------------------------------------------ macOS 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. 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 la construction d'une extension sur une machine differente que celle sur laquelle le code serveur a ete construit, vous pourriez avoir besoin de forcer l'utilisation d'un chemin sysroot different. Pour cela, configurez PG_SYSROOT ainsi par exemple 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 parce qu'elle empeche de passer 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 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. C'est une compilation totalement native qui n'utilise aucun logiciel supplementaire comme MinGW. Un installeur est disponible sur le serveur web officiel de PostgreSQL. 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 construire 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 ayez 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 de problemes vous aurez ; les details sont ci-dessous. ------------------------------------------------------------------------ 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. Il y a eu des problemes rapportes a l'utilisation de GCC 2.95.1 ; des versions de GCC 2.95.3 ou superieure sont recommandees. 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 voulez des packages pour des plus anciennes versions 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, c'est probablement un cas 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 l'amener au 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. ------------------------------------------------------------------------ La compilation 64-bit plante parfois Dans Solaris 7 et precedentes, la version 64 bits de la libc a une routine vsnprintf boguee, qui genere des << core dumps >> aleatoires dans PostgreSQL. Le contournement le plus simple connu est de forcer PostgreSQL a utiliser sa propre version de vsnprintf plutot que celle de la bibliotheque. Pour faire ceci, apres avoir execute << configure >>, editez un des fichiers produits par << configure >>. Dans << src/Makefile.global >>, modifiez la ligne LIBOBJS = par LIBOBJS = snprintf.o (Il pourrait y avoir d'autres fichiers deja listes dans cette variable. L'ordre est sans importance.) Puis compilez comme d'habitude. ------------------------------------------------------------------------ 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 qui modifient le comportement des operations a virgule flottante et le traitement de errno (par exemple, << -fast >>). Ces options pourraient amener des comportements PostgreSQL non standard, par exemple dans le calcul des dates/temps. 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, ce qui fait que 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.