Ce document chapitre décrit l'installation de PostgreSQL™ en utilisant le code source. (Ce document chapitre peut être ignoré lors de l'installation d'une distribution pré-empaquetée, paquet RPM ou Debian, par exemple. Il est alors plus utile de lire les instruction du mainteneur du paquet.)
./configure gmake su gmake 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 document chapitre est la version longue.
En général, les plateformes style unix modernes sont capables d'exécuter PostgreSQL™. Les plateformes sur lesquelles des tests ont été effectués sont listées dans la Section 1.9, « Plateformes supportées » ci-après. Dans le répertoire doc de la distribution, il y a plusieurs FAQ spécifiques à des plateformes particulières à consulter en cas de difficultés.
Les logiciels suivants sont nécessaires pour compiler PostgreSQL™ :
GNU make est nécessaire ; les autres programmes make ne fonctionnent pas. GNU make est souvent installé sous le nom gmake ; ce document y fait toujours référence sous ce nom (sur certains système, GNU make est l'outil par défaut et est nommé make). Pour connaître la version utilisée, saisir
gmake --version
Il est recommandé d'avoir une version postérieure à la version 3.76.1.
Il est nécessaire d'avoir un compilateur C ISO/ANSI (au minimum compatible avec C89). Une version récente de GCC™ est recommandée mais PostgreSQL™ est connu pour être compilable avec de nombreux compilateurs de divers vendeurs.
tar est requis pour déballer la distribution des sources, associé à gzip ou bzip2. De plus, gzip est nécessaire pour installer la documentation.
La bibliothèque GNU Readline™ est utilisée par défaut. Elle permet à psql (l'interpréteur de ligne de commandes SQL de PostgreSQL) de se souvenir de chaque commande saisie, et permet d'utiliser les touches de flêches pour rappeler et éditer les commandes précédentes. C'est très pratique et fortement recommandé. Pour ne pas l'utiliser, il faut préciser --without-readline au moment de l'exécution de la commande configure. Une alternative possible est l'utilisation de la bibliothèqe libedit sous license BSD, développée au début sur NetBSD™. La bibliothèque libedit est compatible GNU Readline™ et est utilisée si cette dernière n'est pas trouvée ou si --with-libedit-preferred est utilisé sur la ligne de commande de configure. Lorsqu'une distribution Linux à base de paquets est utilisée, si les paquets readline et readline-devel sont séparés, il faut impérativement installer les deux.
La bibliothèque de compression zlib™ est utilisée par défaut. Pour ne pas l'utiliser, il faut préciser --without-zlib à configure. Cela a pour conséquence de désactiver le support des archives compressées dans pg_dump et pg_restore.
Les paquets suivants sont optionnels. S'ils ne sont pas obligatoires lors d'une compilation par défaut de PostgreSQL™, ils le deviennent lorsque certaines options sont utilisées, comme cela est expliqué par la suite.
Pour installer le langage procédural PL/Perl, une installation complète de Perl™, comprenant la bibliothèque libperl et les fichiers d'en-tête, est nécessaire.
Comme PL/Perl est une bibliothèque partagée, la bibliothèque libperl doit aussi être partagée sur la plupart des plateformes. C'est désormais le choix par défaut dans les versions récentes de Perl™, mais ce n'était pas le cas dans les versions plus anciennes. Dans tous les cas, c'est du ressort de celui qui installe Perl. Si vous avez l'intention d'avoir plus qu'une utilisation occasionnelle de PL/Perl, vous devez vous assurer que l'installation de Perl™ a été faite avec l'option usemultiplicity activée (perl -V vous indiquera si c'est le cas).
Si la bibliothèque partagée, nécessaire, n'est pas présente, un message d'avertissement tel que celui qui suit apparaît à la compilation :
*** Cannot build PL/Perl because libperl is not a shared library. *** You might have to rebuild your Perl installation. Refer to *** the documentation for details.
(Si la sortie écran est ignorée, on peut constater que la bibliothèque plperl.so de PL/Perl, ou similaire, n'est pas installée.) Si ce message est affiché, il faut recompiler et réinstaller Perl™ manuellement pour pouvoir compiler PL/Perl. Lors de la phase de configuration de Perl™, il faut demander une bibliothèque partagée.
Pour compiler le langage de programmation serveur PL/Python, il faut que Python™ soit installé avec les fichiers d'en-tête et le module distutils. Le module distutils est inclus par défaut avec Python™ 1.6 et les versions suivantes ; les utilisateurs des versions précédentes de Python™ doivent l'installer.
Puisque PL/Python doit être une bibliothèque partagée, la bibliothèque libpython doit l'être aussi sur la plupart des plateformes. Ce n'est pas le cas des installations par défaut de Python. Si, après la compilation et l'installation de PostgreSQL™, il existe un fichier nommé plpython.so (des extensions différentes sont possibles), tout va bien. Sinon, il est fort probable qu'un avertissement semblable à celui qui suit soit apparu :
*** Cannot build PL/Python because libpython is not a shared library. *** You might have to rebuild your Python installation. Refer to *** the documentation for details.
Ce qui signifie qu'il faut recompiler (une partie de) Python™ pour créer cette bibliothèque partagée.
En cas de problèmes, on peut exécuter le configure de Python™ 2.3 ou ultérieur en utilisant le commutateur --enable-shared. Sur certains systèmes d'exploitation, il n'est pas nécessaire de construire une bibliothèque partagée, mais il faut en convaincre le système de construction de PostgreSQL™. Le fichier Makefile du répertoire src/pl/plpython donne des détails complémentaires.
Pour construire le langage procédural PL/Tcl, Tcl™ doit être installé. Si une version antérieure à la version 8.4 de Tcl™, est utilisée, on s'assurera qu'il a été construit sans le support du multi-thread.
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 nécessaire. Certains systèmes d'exploitation l'intégrent (par exemple, Linux, NetBSD, Solaris). Pour les autres systèmes, un paquet additionnel peut être téléchargé sur http://www.gnu.org/software/gettext/. Pour utiliser l'implantation Gettext des bibliothèques C GNU, certains utilitaires nécessitent le paquet GNU Gettext™. Il n'est pas nécessaire dans les autres implantations.
Kerberos, OpenSSL™, OpenLDAP™ ou PAM pour bénéficier de l'authentification ou du chiffrement en utilisant ces services.
En cas de compilation à partir d'une arborescence Git et non d'un paquet de sources publié, ou pour faire du développement au niveau serveur, les paquets suivants seront également nécessaires :
GNU Flex et Bison sont nécessaires pour compiler à partir d'un export du Git ou lorsque les fichiers de définition de l'analyseur ou du « scanner » sont modifiés. Les versions nécessaires sont Flex 2.5.4 ou ultérieure et Bison 1.875 ou ultérieure. Les autres programmes lex et yacc ne peuvent pas être utilisés.
Perl est aussi nécessaire pour construire les sources du Git, ou lorsque les fichiers en entrée pour n'importe laquelle des étapes de construction qui utilisent des scripts Perl ont été modifiés. Sous Windows, Perl est nécessaire dans tous les cas.
Si d'autres paquets GNU sont nécessaires, ils peuvent être récupérés sur un site miroir de GNU (voir http://www.gnu.org/order/ftp.html pour la liste) ou sur ftp://ftp.gnu.org/gnu/.
Il est important de vérifier qu'il y a suffisamment d'espace disque disponible. 100 Mo sont nécessaires pour la compilation et 20 Mo pour le répertoire d'installation. Un groupe de bases de données vide nécessite 35 Mo ; les fichiers des bases prennent cinq fois plus d'espace que des fichiers texte contenant les mêmes données. Si des tests de régression sont prévus, 150 Mo supplémentaires sont temporairement nécessaires. On peut utiliser la commande df pour vérifier l'espace disque disponible.
Les sources de PostgreSQL™ 8.4.22 peuvent être obtenues par ftp anonyme sur ftp://ftp.postgresql.org/pub/source/v8.4.22/postgresql-8.4.22.tar.gz. D'autres options de téléchargement sont possibles à partir du site web : http://www.postgresql.org/download/. Après avoir obtenu le fichier, on le décompresse :
gunzip postgresql-8.4.22.tar.gz tar xf postgresql-8.4.22.tar
Cela crée un répertoire postgresql-8.4.22 contenant les sources de PostgreSQL™ dans le répertoire courant. Le reste de la procédure d'installation s'effectue depuis ce répertoire.
Les sources peuvent également être obtenues directement à partir du système de contrôle de version. Pour plus d'informations, voir ???.
Ces instructions supposent que l'installation existante se trouve dans le répertoire /usr/local/pgsql, et que l'aire de données est dans /usr/local/pgsql/data. Il convient de modifier ces chemins en fonction de l'installation actuelle.
Le format de stockage interne des données change typiquement à chaque version majeure de PostgreSQL™. C'est pourquoi, lors de la mise à jour d'une installation qui n'est pas du numéro de version « 8.4.x », il faut sauvegarder et restaurer ses données. Lors d'une mise à jour à partir de PostgreSQL™ « 8.4.x », la nouvelle version peut utiliser les fichiers de données actuels ; les étapes de sauvegarde et de restauration ci-dessous, inutiles, peuvent être ignorées.
Lors de la sauvegarde, il est préférable de s'assurer que la base de données n'est pas actualisée. Non que cela affecte l'intégrité de la sauvegarde, mais parce que les données modifiées ne sont pas incluses. Il peut, dans ce cas, être nécessaire d'éditer les permissions dans le fichier /usr/local/pgsql/data/pg_hba.conf (ou équivalent) pour interdire les accès autres que celui utile à la sauvegarde.
Pour sauvegarder la base, saisir :
pg_dumpall > fichierdesortie
Pour conserver les identifiants d'objets (OID) (lorsqu'ils sont utilisés comme clé étrangère), utiliser l'option -o lors de l'exécution de pg_dumpall.
Pour effectuer la sauvegarde, il est possible d'utiliser la commande pg_dumpall incluse dans la distribution de la version actuelle. Cependant, pour de meilleurs résultats, il est préférable d'utiliser la commande pg_dumpall contenue dans PostgreSQL™ 8.4.22 puisqu'elle corrige les erreurs des versions précédentes. Bien que ce conseil puisse paraître absurde, tant que la nouvelle version n'est pas installée, il convient de le suivre si l'objectif est d'installer la nouvelle version en parallèle de l'ancienne. Dans ce cas, il est possible de terminer normalement l'installation et de transférer les données dans un second temps, ce qui réduit l'indisponibilité.
Arrêter l'ancien serveur :
pg_ctl stop
Sur les systèmes qui lancent PostgreSQL™ au démarrage, il y a probablement un fichier de démarrage qui peut faire la même chose. Par exemple, sur un système Red Hat Linux, cette commande doit fonctionner :
/etc/rc.d/init.d/postgresql stop
En cas de restauration d'une sauvegarde, renommer ou supprimer l'ancien répertoire d'installation. Il est préférable de renommer le répertoire plutôt que de le supprimer, parce qu'en cas de problème, on peut avoir besoin d'y revenir. Le répertoire peut prendre beaucoup d'espace disque. Pour renommer le répertoire, utiliser une commande comme :
mv /usr/local/pgsql /usr/local/pgsql.old
Installer la nouvelle version de PostgreSQL™ comme indiquée dans la prochaine section Section 1.5, « Procédure d'installation ».
Créer un nouveau cluster de bases de données. Ces commandes doivent être exécutées sous le compte superutilisateur initial (qui existe déjà dans le cas d'une mise à jour).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Restaurer le pg_hba.conf précédent et toutes les modifications de postgresql.conf.
Lancer le serveur de bases de données, toujours à partir du compte superutilisateur :
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Enfin, restaurer les données à partir de la sauvegarde avec :
/usr/local/pgsql/bin/psql -d postgres -f outputfile
en utilisant le nouveau psql.
Des informations supplémentaires sont disponibles dans la documentation ???. Cette documentation contient notmamment des instructions sur la manière d'exécuter les deux versions en parallèle.
Configuration
La première étape de la procédure d'installation est de configurer l'arborescence système et de choisir les options intéressantes. Ce qui est fait en exécutant le script configure. Pour une installation par défaut, entrer simplement
./configure
Ce script exécutera de nombreux tests afin de déterminer les valeurs de certaines variables dépendantes du système et de détecter certains aléas relatifs au système d'exploitation. Il créera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a été trouvé (configure peut aussi être exécuté à partir d'un répertoire hors de l'arborescence des sources pour conserver l'arborescence de compilation séparé).
La configuration par défaut compilera le serveur et les utilitaires, aussi bien que toutes les applications clientes et interfaces qui requièrent seulement un compilateur C. Tous les fichiers seront installés par défaut sous /usr/local/pgsql.
Les processus de compilation et d'installation peuvent être personnalisés par l'utilisation d'une ou plusieurs options sur la ligne de commande après configure :
Installe tous les fichiers dans le répertoire PREFIX au lieu du répertoire /usr/local/pgsql. Les fichiers actuels seront installés dans divers sous-répertoires ; aucun fichier ne sera directement installé sous PREFIX.
Pour satisfaire des besoins spécifiques, les sous-répertoires peuvent être personnalisés à l'aide des options qui suivent. Toutefois, en laissant les options par défaut, l'installation est déplaçable, ce qui signifie que le réperoire peut être déplacé après installation. (Cela n'affecte pas les emplacements de man et doc.)
Pour les installations déplaçables, on peut utiliser l'option --disable-rpath de configure. De plus, il faut indiquer au système d'exploitation comment trouver les bibliothèques partagées.
Les fichiers qui dépendent de l'architecture peuvent être installés dans un répertoire différent, EXEC-PREFIX, de celui donné par PREFIX. Ce qui peut être utile pour partager les fichiers dépendant de l'architecture entre plusieurs machines. S'il est omis, EXEC-PREFIX est égal à PREFIX et les fichiers dépendant seront installés sous la même arborescence que les fichiers indépendants de l'architecture, ce qui est probablement le but recherché.
Précise le répertoire des exécutables. Par défaut, il s'agit de EXEC-PREFIX/bin, ce qui signifie /usr/local/pgsql/bin.
Précise le répertoire de divers fichiers de configuration. Par défaut, il s'agit de PREFIX/etc.
Précise le répertoire d'installation des bibliothèques et des modules chargeables dynamiquement. Par défaut, il s'agit de EXEC-PREFIX/lib.
Précise le répertoire d'installation des en-têtes C et C++. Par défaut, il s'agit de PREFIX/include.
Indique le répertoire racine de différents types de fichiers de données en lecture seule. Cela ne sert qu'à paramétrer des valeurs par défaut pour certaines des options suivantes. La valeur par défaut est PREFIX/share.
Indique le répertoire pour les fichiers de données en lecture seule utilisés par les programmes installés. La valeur par défaut est DATAROOTDIR. Cela n'a aucun rapport avec l'endroit où les fichiers de base de données seront placés.
Indique le répertoire pour installer les données locales, en particulier les fichiers catalogues de traductions de messages. La valeur par défaut est DATAROOTDIR/locale.
Les pages man fournies avec PostgreSQL™ seront installées sous ce répertoire, dans leur sous-répertoire manx respectif. Par défaut, il s'agit de DATAROOTDIR/man.
Configure le répertoire racine pour installer les fichiers de documentation, sauf les pages « man ». Ceci ne positionne la valeur par défaut que pour les options suivantes. La valeur par défaut pour cette option est DATAROOTDIR/doc/postgresql.
La documentation formatée en HTML pour PostgreSQL™ sera installée dans ce répertoire. La valeur par défaut est DATAROOTDIR.
Une attention toute particulière a été prise afin de rendre possible l'installation de PostgreSQL™ dans des répertoires partagés (comme /usr/local/include) sans interférer avec des noms de fichiers relatifs au reste du système. En premier lieu, le mot « /postgresql » est automatiquement ajouté aux répertoires datadir, sysconfdir et docdir, à moins que le nom du répertoire à partir de la racine contienne déjà le mot « postgres » où « pgsql ». Par exemple, si /usr/local est choisi comme préfixe, la documentation sera installée dans /usr/local/doc/postgresql, mais si le préfixe est /opt/postgres, alors il sera dans /opt/postgres/doc. Les fichiers d'en-têtes publiques C de l'interface cliente seront installés sous includedir et sont indépendants des noms de fichiers relatifs au reste du système. Les fichiers d'en-têtes privés et les fichiers d'en-têtes du serveur sont installés dans des répertoires privés sous includedir. Voir la documentation de chaque interface pour savoir comment obtenir ces fichiers d'en-tête. Enfin, un répertoire privé sera aussi créé si nécessaire sous libdir pour les modules chargeables dynamiquement.
REPERTOIRES est une liste de répertoires séparés par des caractères deux points (:) qui sera ajoutée à la liste de recherche des fichiers d'en-tête. Si vous avez des paquetages optionnels (tels que Readline GNU) installés dans des répertoires non conventionnels, vous pouvez utiliser cette option et certainement l'option --with-libraries correspondante.
Exemple : --with-includes=/opt/gnu/include:/usr/sup/include.
REPERTOIRES est une liste de recherche de répertoires de bibliothèques séparés par des caractères deux points (:). Si des paquets sont installés dans des répertoires non conventionnels, il peut s'avérer nécessaire d'utiliser cette option (et l'option correspondante --with-includes).
Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib.
Permet de mettre en place le support des langues natives (NLS). C'est la possibilité d'afficher les messages des programmes dans une langue autre que l'anglais. LANGUES est une liste, optionnelle, des codes des langues que vous voulez supporter séparés par un espace. Par exemple, --enable-nls='de fr' (l'intersection entre la liste et l'ensemble des langues traduites actuellement sera calculée automatiquement). En l'absence de liste, toutes les traductions disponibles seront installées.
Pour utiliser cette option, une implantation de l'API Gettext est nécessaire ; voir après.
Positionne NUMERO comme numéro de port par défaut pour le serveur et les clients. La valeur par défaut est 5432. Le port peut toujours être changé ultérieurement mais, précisé ici, les exécutables du serveur et des clients auront la même valeur par défaut, ce qui est vraiment très pratique. Habituellement, la seule bonne raison de choisir une valeur autre que celle par défaut est l'exécution de plusieurs serveurs PostgreSQL™ sur la même machine.
Permet l'utilisation du langage de procédures PL/Perl côté serveur.
Permet la compilation du langage de procédures PL/Python.
Permet la compilation du langage de procédures PL/Tcl.
Tcl installe les fichiers tclConfig.sh, contenant certaines informations de configuration nécessaires pour compiler le module d'interfaçage avec Tcl. Ce fichier est trouvé automatiquement mais, si pour utiliser une version différente de Tcl, il faut indiquer le répertoire où le trouver.
Construire avec le support de l'authentification GSSAPI. Sur de nombreux systèmes, GSSAPI (qui fait habituellement partie d'une installation Kerberos) n'est pas installé dans un emplacement recherché par défaut (c'est-à-dire /usr/include, /usr/lib), donc vous devez utiliser les options --with-includes et --with-libraries en plus de cette option. configure vérifiera les fichiers d'en-têtes nécessaires et les bibliothèques pour s'assurer que votre installation GSSAPI est suffisante avant de continuer.
Compile le support d'authentification de Kerberos 5. Sur beaucoup de systèmes, le système Kerberos n'est pas installé à un emplacement recherché par défaut (c'est-à-dire /usr/include, /usr/lib), donc vous devez utiliser les options --with-includes et --with-libraries en plus de cette option. configure vérifiera les fichiers d'en-tête et les bibliothèques requis pour s'assurer que votre installation Kerberos est suffisante avant de continuer
Le nom par défaut du service principal de Kerberos (aussi utilisé par GSSAPI). postgres est pris par défaut. Il n'y a habituellement pas de raison de le changer sauf dans le cas d'un environnement Windows, auquel cas il doit être mis en majuscule, POSTGRES.
Compile le support de connexion SSL (chiffrement). Le paquetage OpenSSL™ doit être installé. configure vérifiera que les fichiers d'en-tête et les bibliothèques soient installés pour s'assurer que votre installation d'OpenSSL™ est suffisante avant de continuer.
Compile le support PAM (Modules d'Authentification Pluggable).
Demande l'ajout du support de LDAP pour l'authentification et la recherche des paramètres de connexion (voir la documentation sur l'authentification des clients et libpq??? et ???). Sur Unix, cela requiert l'installation du paquet OpenLDAP™. Sur Windows, la bibliothèque WinLDAP™ est utilisée par défaut. configure vérifiera l'existence des fichiers d'en-tête et des bibliothèques requis pour s'assurer que votre installation d'OpenLDAP™ est suffisante avant de continuer.
Évite l'utilisation de la bibliothèque Readline (et de celle de libedit). Cela désactive l'édition de la ligne de commande et l'historique dans psql, ce n'est donc pas recommandé.
Favorise l'utilisation de la bibliothèque libedit (sous licence BSD) plutôt que Readline (GPL). Cette option a seulement un sens si vous avez installé les deux bibliothèques ; dans ce cas, par défaut, Readline est utilisé.
Compile le support de Bonjour. Ceci requiert le support de Bonjour dans votre système d'exploitation. Recommandé sur Mac OS X.
Utilise la bibliothèque OSSP UUID lors de la construction du module contrib/uuid-ossp. Cette bibliothèque fournit des fonctions pour générer les UUID.
Construit avec libxml (active le support SQL/XML). Une version 2.6.23 ou ultérieure de libxml est requise pour cette fonctionnalité.
Libxml installe un programme xml2-config qui est utilisé pour détecter les options du compilateur et de l'éditeur de liens. PostgreSQL l'utilisera automatiquement si elle est trouvée. Pour indiquer une installation de libxml dans un emplacement inhabituel, vous pouvez soit configurer la variable d'environnement XML2_CONFIG pour pointer vers le programme xml2-config appartenant à l'installation, ou utiliser les options --with-includes et --with-libraries.
Utilise libxslt pour construire contrib/xml2. Le module contrib/xml2 se base sur cette bibliothèque pour réaliser les transformations XSL du XML.
Désactive le support pour le stockage des intervalles et horodatages en entier 64 bits, et stocke les valeurs de type date/temps en temps que nombre à virgule flottante à la place. Le stockage à virgule flottante des dates/temps était la valeur par défaut dans les versions de PostgreSQL™ antérieures à la 8.4, mais est maintenant obsolète parce qu'il ne permet pas une précision à la microseconde pour toute l'étendue des valeurs timestamp. Toutefois, le stockage des dates/temps à base d'entiers nécessite un type entier de 64 bits. Par conséquent, cette option peut être utilisée quand ce type de données n'est pas disponible, ou pour maintenir la compatibilité avec des applications écrites pour des versions antérieures de PostgreSQL™. Voir la documentation à propos des types dates/temps ??? pour plus d'informations.
Désactive le passage « par valeur » des valeurs float4, entraînant leur passage « par référence » à la place. Cette option a un coût en performance, mais peut être nécessaire pour maintenir la compatibilité avec des anciennes fonctions créées par l'utilisateur qui sont écrites en C et utilisent la convention d'appel « version 0 ». Une meilleure solution à long terme est de mettre à jour toutes ces fonctions pour utiliser la convention d'appel « version 1 ».
Désactive le passage « par valeur » des valeurs float8, entraînant leur passage « par référence » à la place. Cette option a un coût en performance, mais peut être nécessaire pour maintenir la compatibilité avec des anciennes fonctions créées par l'utilisateur qui sont écrites en C et utilisent la convention d'appel « version 0 ». Une meilleure solution à long terme est de mettre à jour toutes ces fonctions pour utiliser la convention d'appel « version 1 ». Notez que cette option n'affecte pas que float8, mais aussi int8 et quelques types apparentés comme timestamp. Sur les plateformes 32 bits, --disable-float8-byval est la valeur par défaut, et il n'est pas permis de sélectionner --enable-float8-byval.
Indique la taille d'un segment, en gigaoctets. Les grandes tables sont divisées en plusieurs fichiers du système d'exploitation, chacun de taille égale à la taille de segment. Cela évite les problèmes avec les limites de tailles de fichiers qui existent sur de nombreuses plateformes. Si votre système d'exploitation supporte les fichiers de grande taille (« largefile »), ce qui est le cas de la plupart d'entre eux de nos jours, vous pouvez utiliser une plus grande taille de segment. Cela peut être utile pour réduire le nombre de descripteurs de fichiers qui peuvent être utilisés lors de travail sur des très grandes tables. Attention à ne pas sélectionner une valeur plus grande que ce qui est supporté par votre plateforme et le(s) système(s) de fichiers que vous prévoyez d'utiliser. D'autres outils que vous pourriez vouloir utiliser, tels que tar, pourraient aussi limiter la taille maximum utilisable pour un fichier. Il est recommandé, même si pas vraiment nécessaire, que cette valeur soit un multiple de 2. Notez que changer cette valeur impose de faire un initdb.
Indique la taille d'un bloc, en kilooctets. C'est l'unité de stockage et d'entrée/sortie dans les tables. La valeur par défaut, 8 kilooctets, est appropriée pour la plupart des cas ; mais d'autres valeurs peuvent être utilises dans des cas spéciaux. Cette valeur doit être une puissance de 2 entre 1 et 32 (kilooctets). Notez que changer cette valeur impose de faire un initdb.
Indique la taille d'un segment WAL, en mégaoctets. C'est la taille de chaque fichier individuel dans les journaux de transactions. Il peut être utile d'ajuster cette taille pour contrôler la granularité du transport de journaux de transations. La valeur par défaut est de 16 mégaoctets. La valeur doit être une puissance de 2 entre 1 et 6 (mégaoctets). Notez que changer cette valeur impose de faire un initdb.
Indique la taille d'un bloc WAL, en kilooctets. C'est l'unité de stockage et d'entrée/sortie dans le journal des transactions. La valeur par défaut, 8 kilooctets, est appropriée pour la plupart des cas ; mais d'autres valeurs peuvent être utilises dans des cas spéciaux. La valeur doit être une puissance de 2 entre 1 et 64 (kilooctets).
Autorise le succès de la construction y compris lorsque PostgreSQL™ n'a pas le support spinlock du CPU pour la plateforme. Ce manque de support résultera en des performances faibles ; du coup, cette option devra seulement être utilisée si la construction échoue et vous informe du manque de support de spinlock sur votre plateforme. Si cette option est requise pour construire PostgreSQL™ sur votre plateforme, merci de rapporter le problème aux développeurs de PostgreSQL™.
Rend les bibliothèques clientes compatibles avec les threads. Ceci permet des threads concurrents dans les programmes libpq et ECPG ce qui leur permet de gérer en toute sûreté leur connexions privées. Cette option requiert un support adéquat des threads sur votre système d'exploitation.
PostgreSQL™ inclut sa propre base de données des fuseaux horaires, nécessaire pour les opérations sur les dates et les heures. Cette base de données est en fait compatible avec la base de fuseaux horaires « zoneinfo » fournie par de nombreux systèmes d'exploitation comme FreeBSD, Linux et Solaris, donc ce serait redondant de l'installer une nouvelle fois. Quand cette option est utilisée, la base des fuseaux horaires, fournie par le système, dans RÉPERTOIRE est utilisée à la place de celle inclus dans la distribution des sources de PostgreSQL. RÉPERTOIRE doit être indiqué avec un chemin absolu. /usr/share/zoneinfo est un répertoire très probable sur certains systèmes d'exploitation. Notez que la routine d'installation ne détectera pas les données de fuseau horaire différentes ou erronées. Si vous utilisez cette option, il vous est conseillé de lancer les tests de régression pour vérifier que les données de fuseau horaire que vous pointez fonctionnent correctement avec PostgreSQL™.
Cette option a pour cible les distributeurs de paquets binaires qui connaissent leur système d'exploitation. Le principal avantage d'utiliser cette option est que le package PostgreSQL n'aura pas besoin d'être mis à jour à chaque fois que les règles des fuseaux horaires changent. Un autre avantage est que PostgreSQL peut être cross-compilé plus simplement si les fichiers des fuseaux horaires n'ont pas besoin d'être construit lors de l'installation.
Évite l'utilisation de la bibliothèque Zlib. Cela désactive le support des archives compressées dans pg_dump et pg_restore. Cette option est seulement là pour les rares systèmes qui ne disposent pas de cette bibliothèque.
Compile tous les programmes et bibliothèques en mode de débogage. Cela signifie que vous pouvez exécuter les programmes via un débogueur pour analyser les problèmes. Cela grossit considérablement la taille des exécutables et, avec des compilateurs autres que GCC, habituellement, cela désactive les optimisations du compilateur, provoquant des ralentissements. Cependant, mettre ce mode en place est extrêmement utile pour repérer les problèmes. Actuellement, cette option est recommandée pour les installations en production seulement si vous utilisez GCC. Néanmoins, vous devriez l'utiliser si vous développez ou si vous utilisez une version béta.
Si vous utilisez GCC, les programmes et bibliothèques sont compilés avec de l'instrumentation de test de couverture de code. Quand ils sont exécutés, ils génèrent des fichiers dans le répertoire de compilation avec des métriques de couverture de code. Voir ??? pour davantage d'informations. Cette option ne doit être utilisée qu'avec GCC et uniquement en phase de développement.
En cas d'utilisation de GCC, tous les programmes et bibliothèques sont compilés pour qu'elles puissent être profilées. À la sortie du processus serveur, un sous-répertoire sera créé pour contenir le fichier gmon.out à utiliser pour le profilage. Cette option est à utiliser seulement avec GCC lors d'un développement.
Permet la vérification des assertions par le serveur qui teste de nombreux cas de conditions « impossibles ». Ce qui est inestimable dans le cas de développement, mais les tests peuvent ralentir sensiblement le système. Activer cette option n'influe pas sur la stabilité de votre serveur ! Les assertions vérifiées ne sont pas classées par ordre de sévérité et il se peut qu'un bogue anodin fasse redémarrer le serveur s'il y a un échec de vérification. Cette option n'est pas recommandée dans un environnement de production mais vous devriez l'utiliser lors de développement ou pour les versions béta.
Active la recherche automatique des dépendances. Avec cette option, les fichiers makefile sont appelés pour recompiler les fichiers objet dès qu'un fichier d'en-tête est modifié. C'est pratique si vous faites du développement, mais inutile si vous ne voulez que compiler une fois et installer. Pour le moment, cette option ne fonctionne qu'avec GCC.
Compile PostgreSQL™ avec le support de l'outil de trace dynamique, DTrace. Voir ??? pour plus d'informations.
Pour pointer vers le programme dtrace, la variable d'environnement DTRACE doit être configurée. Ceci sera souvent nécessaire car dtrace est typiquement installé sous /usr/sbin, qui pourrait ne pas être dans le chemin.
Des options supplémentaires en ligne de commande peuvent être indiquées dans la variable d'environnement DTRACEFLAGS pour le programme dtrace. Sur Solaris, pour inclure le support de DTrace dans un exécutable 64-bit, ajoutez l'option DTRACEFLAGS="-64" pour configure. Par exemple, en utilisant le compilateur GCC :
./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
En utilisant le compilateur de Sun :
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
Si vous préférez utiliser un compilateur C différent de ceux listés par configure, positionnez la variable d'environnement CC pour qu'elle pointe sur le compilateur de votre choix. Par défaut, configure pointe sur gcc s'il est disponible, sinon il utilise celui par défaut de la plateforme (habituellement cc). De façon similaire, vous pouvez repositionner les options par défaut du compilateur à l'aide de la variable CFLAGS.
Les variables d'environnement peuvent être indiquées sur la ligne de commande configure, par exemple :
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
Voici une liste des variables importantes qui sont configurables de cete façon :
programme Bison
compilateur C
options à passer au compilateur C
préprocesseur C
options à passer au préprocesseur C
emplacement du programme dtrace
options à passer au programme dtrace
programme Flex
options à passer à l'éditeur de liens
options de l'éditeur de liens pour la création des liens des bibliothèques partagées
programme msgfmt pour le support des langues
chemin complet vers l'interpréteur Perl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Perl.
chemin complet vers l'interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python.
chemin complet vers l'interpréteur Tcl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Tcl, et il sera substitué dans des scripts Tcl.
programme xml2-config utilisé pour localiser l'installation de libxml.
Compilation
Pour démarrer la compilation, saisissez
gmake
(Rappelez-vous d'utiliser GNU make). La compilation prendra quelques minutes, suivant de votre matériel. La dernière ligne affichée devrait être
All of PostgreSQL is successfully made. Ready to install.
Tests de régression
Si vous souhaitez tester le serveur nouvellement compilé avant de l'installer, vous pouvez exécuter les tests de régression à ce moment. Les tests de régression sont une suite de tests qui vérifient que PostgreSQL™ fonctionne sur votre machine tel que les développeurs l'espèrent. Saisissez
gmake check
(cela ne fonctionne pas en tant que root ; faites-le en tant qu'utilisateur sans droits). Le fichier src/test/regress/README et la documentation contiennentLe ??? contient des détails sur l'interprétation des résultats de ces tests. Vous pouvez les répéter autant de fois que vous le voulez en utilisant la même commande.
Installer les fichiers
Si vous mettez à jour une version existante et que vous placez les fichiers au même endroit que les anciens, assurez-vous d'avoir sauvegardé vos données et arrêté l'ancien serveur avant de continuer, comme l'explique la Section 1.4, « Mise à jour » ci-après.
Pour installer PostgreSQL™, saisissez
gmake install
Cela installera les fichiers dans les répertoires spécifiés dans l'Étape 1. Assurez-vous d'avoir les droits appropriés pour écrire dans ces répertoires. Normalement, vous avez besoin d'être superutilisateur pour cette étape. Une alternative consiste à créer les répertoires cibles à l'avance et à leur donner les droits appropriées.
Vous pouvez utiliser gmake install-strip en lieu et place de gmake install pour dépouiller l'installation des exécutables et des bibliothèques. Cela économise un peu d'espace disque. Si vous avez effectué la compilation en mode de débogage, ce dépouillage l'enlèvera, donc ce n'est à faire seulement si ce mode n'est plus nécessaire. install-strip essaie d'être raisonnable en sauvegardant de l'espace disque mais il n'a pas une connaissance parfaite de la façon de dépouiller un exécutable de tous les octets inutiles. Ainsi, si vous voulez sauvegarder le maximum d'espace disque, vous devrez faire le travail à la main.
L'installation standard fournit seulement les fichiers en-têtes nécessaires pour le développement d'applications clientes ainsi que pour le développement de programmes côté serveur comme des fonction personnelles ou des types de données écrits en C (avant PostgreSQL™ 8.0, une commande gmake install-all-headers séparée était nécessaire pour ce dernier point mais cette étape a été intégrée à l'installation standard).
Installation du client uniquement : Si vous voulez uniquement installer les applications clientes et les bibliothèques d'interface, alors vous pouvez utilisez ces commandes :
gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install
src/bin comprend quelques exécutables utilisés seulement par le serveur mais ils sont petits.
Enregistrer eventlog sur Windows : Pour enregistrer une bibliothèque eventlog sur Windows grâce au système d'exploitation, exécutez cette commande après l'installation :
regsvr32 pgsql_library_directory/pgevent.dll
Ceci crée les entrées du registre utilisées par le visualisateur d'événements.
Désinstallation : Pour désinstaller, utilisez la commande gmake uninstall. Cependant, cela ne supprimera pas les répertoires créés.
Nettoyage : Après l'installation, vous pouvez libérer de l'espace en supprimant les fichiers issus de la compilation des répertoires sources à l'aide de la commande gmake clean. Cela conservera les fichiers créés par la commande configure, ainsi vous pourrez tout recompiler ultérieurement avec gmake. Pour remettre l'arborescence source dans l'état initial, utilisez gmake distclean. Si vous voulez effectuer la compilation pour diverses plateformes à partir des mêmes sources vous devrez d'abord refaire la configuration à chaque fois (autrement, utilisez un répertoire de construction séparé pour chaque plateforme, de façon à ce que le répertoire des sources reste inchangé).
Si vous avez compilé et que vous vous êtes rendu compte que les options de configure sont fausses ou si vous changez quoique ce soit que configure prenne en compte (par exemple, la mise à jour d'applications), alors faire un gmake distclean avant de reconfigurer et recompiler est une bonne idée. Sans ça, vos changements dans la configuration ne seront pas répercutés partout où il faut.
Sur certains systèmes qui utilisent les bibliothèques partagées (ce que font de nombreux systèmes), vous avez besoin de leurs spécifier comment trouver les nouvelles bibliothèques partagées. Les systèmes sur lesquels ce n'est pas nécessaire comprennent BSD/OS, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, Tru64 UNIX (auparavant Digital UNIX) et Solaris.
La méthode pour le faire varie selon la plateforme, mais la méthode la plus répandue consiste à 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 donnée à --libdir dans l'Étape 1. Vous pouvez mettre ces commandes dans un script de démarrage tel que /etc/profile ou ~/.bash_profile. Certaines informations pertinentes au sujet de mises en garde associées à cette méthode peuvent être trouvées sur http://www.visi.com/~barr/ldpath.html.
Sur certains systèmes, il peut être préférable de renseigner la variable d'environnement LD_RUN_PATH avant la compilation.
Avec Cygwin, placez le répertoire des bibliothèques dans la variable PATH ou déplacez les fichiers .dll dans le répertoire bin.
En cas de doute, référez-vous aux pages de man de votre système (peut-être ld.so ou rld). Si vous avez ultérieurement un message tel que
psql: error in loading shared libraries libpq.so.2.1: cannot open shared object file: No such file or directory
alors cette étape est vraiment nécessaire. Faites-y attention.
Si votre système d'exploitation est BSD/OS, Linux ou SunOS 4 et que vous avez les accès de superutilisateur, vous pouvez exécuter :
/sbin/ldconfig /usr/local/pgsql/lib
(ou le répertoire équivalent) après l'installation pour permettre à l'éditeur de liens de trouver les bibliothèques partagées plus rapidement. Référez-vous aux pages man portant sur ldconfig pour plus d'informations. Pour les systèmes d'exploitation FreeBSD, NetBSD et OpenBSD, la commande est :
/sbin/ldconfig -m /usr/local/pgsql/lib
Les autres systèmes d'exploitation ne sont pas connus pour avoir de commande équivalente.
Si l'installation a été réalisée dans /usr/local/pgsql ou à un autre endroit qui n'est pas dans les répertoires contenant les exécutables par défaut, vous devez ajouter /usr/local/pgsql/bin (ou le répertoire fourni à --bindir au moment de l'Étape 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 système trouve la documentation man, il vous faut ajouter des lignes telles que celles qui suivent à votre fichier d'initialisation du shell, à moins que vous installiez ces pages dans un répertoire où elles sont mises normalement :
MANPATH=/usr/local/pgsql/man:$MANPATH export MANPATH
Les variables d'environnement PGHOST et PGPORT indiquent aux applications clientes l'hôte et le port du serveur de base. Elles surchargent les valeurs utilisées lors de la compilation. Si vous exécutez des applications clientes à distance, alors c'est plus pratique si tous les utilisateurs peuvent paramétrer PGHOST. Ce n'est pas une obligation, cependant, la configuration peut être communiquée via les options de lignes de commande à la plupart des programmes clients.
La suite est un résumé rapide de la façon de faire fonctionner PostgreSQL™ une fois l'installation terminée. La documentation principale contient plus d'informations.
Créer un compte utilisateur pour le serveur PostgreSQL™. C'est cet utilisateur qui fera démarrer le serveur. Pour un usage en production, vous devez créer un compte sans droits (« postgres » est habituellement utilisé). Si vous n'avez pas les accès superutilisateur ou si vous voulez juste regarder, votre propre compte utilisateur est suffisant. Mais, utiliser le compte superutilisateur pour démarrer le serveur est risqué (au point de vue sécurité) et ne fonctionnera pas.
adduser postgres
Faire l'installation de la base de données avec la commande initdb. Pour exécuter initdb, vous devez être connecté sur votre serveur avec le compte PostgreSQL™. Cela ne fonctionnera pas avec le compte superutilisateur.
root# mkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data root# su - postgres postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
L'option -D spécifie le répertoire où les données seront stockées. Vous pouvez utiliser le chemin que vous voulez, il n'a pas à être sous le répertoire de l'installation. Avant de lancer initdb, assurez-vous que le compte serveur peut écrire dans ce répertoire (ou le créer s'il n'existe pas), comme c'est montré ici.
À ce moment, si vous n'utilisez pas l'option -A de initdb, vous devez modifier le fichier pg_hba.conf pour contrôler les accès en local du serveur avant de le lancer. La valeur par défaut est de faire confiance à tous les utilisateurs locaux.
L'étape initdb précédente vous a indiqué comment démarrer le serveur de base. Maintenant, faites-le. La commande doit ressembler à :
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Cela démarrera le serveur en avant-plan. Pour le mettre en arrière plan faites quelque chose comme :
nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \
</dev/null >>server.log 2>&1 </dev/null &
Pour arrêter le serveur fonctionnant en arrière-plan, vous pouvez saisir :
kill `cat /usr/local/pgsql/data/postmaster.pid`
Créer une base de données :
createdb testdb
Ensuite, entrez
psql testdb
pour vous connecter à la base. À l'invite, vous pouvez saisir des commandes SQL et commencer l'expérimentation.
La distribution de PostgreSQL™ comprend un document compréhensible que vous devriez lire de temps en temps. Après l'installation, le document peut être lu en faisant pointer votre navigateur internet sur /usr/local/pgsql/doc/html/index.html, excepté si vous avez changé les répertoires d'installation.
Le premier chapitre de la documentation est un tutoriel qui devrait être votre première lecture si vous êtes nouveau dans le monde des bases de données SQL. Si vous êtes familier avec les concepts des bases de données, alors vous voudrez commencer avec la partie administration du serveur qui contient des informations sur la façon de mettre en place le serveur de base, les bases des utilisateurs et l'authentification.
Normalement, vous voudrez faire en sorte que le serveur de base démarre automatiquement au boot de la machine. Pour ce faire, quelques suggestions se trouvent dans la documentation.
Faire les tests de régression sur le serveur installé (en utilisant gmake installcheck). Si vous ne l'avez pas fait auparavant, vous devriez définitivement le faire maintenant. C'est aussi expliqué dans la documentation.
Par défaut, PostgreSQL™ est configuré pour fonctionner sur un matériel mimimal. Ceci lui permet de fonctionner sur pratiquement toutes les configurations matérielles. Néanmoins, la configuration par défaut n'est pas conçue pour des performances optimales. Pour disposer des meilleures performances, plusieurs paramètres serveurs doivent être ajustés, les deux plus communs étant shared_buffers et work_mem. Les autres paramètres mentionnés dans la documentation affectent aussi les performances.
Une platforme (c'est-à-dire une combinaison d'un processeur et d'un système d'exploitation) est considérée supportée par la communauté de développeur de PostgreSQL™ si le code permet le fonctionnement sur cette plateforme et que la construction et les tests de regréssion ont été récemment vérifiés sur cette plateforme. Actuellement, la plupart des tests de compatibilité de plateforme se fait automatiquement par des machines de tests dans la ferme de construction de PostgreSQL. Si vous êtes intéressés par l'utilisation de PostgreSQL™ sur une plateforme qui n'est pas représentée dans la ferme de construction, mais pour laquelle le code fonctionne ou peut fonctionner, nous vous suggérons fortement de construction une machine qui sera membre de la ferme pour que la compatibilité puisse être assurée dans la durée.
En général, PostgreSQL™ doit fonctionner sur les architectures processeur suivantes : x86, x86_64, IA64, PowerPC, PowerPC 64, S/390, S/390x, Sparc, Sparc 64, Alpha, ARM, MIPS, MIPSEL, M68K et PA-RISC. Un support du code existe pour M32R, NS32K et VAX mais ces architectures n'ont pas été testées récemment à notre connaissance. Il est souvent possible de construire PostgreSQL™ sur un type de processeur non supporté en précisant --disable-spinlocks. Cependant, les performance en souffriront.
PostgreSQL™ doit fonctionner sur les systèmes d'exploitation suivants : Linux (toutes les distributions récentes), Windows (Win2000 SP4 et ultérieure), FreeBSD, OpenBSD, NetBSD, Mac OS X, AIX, HP/UX, IRIX, Solaris, Tru64 Unix et UnixWare. D'autres systèmes style Unix peuvent aussi fonctionner mais n'ont pas été récemment testés. Dans la plupart des cas, toutes les architectures processeurs supportées par un système d'exploitation donné fonctionneront. Cherchez dans le répertoire Section 1.10, « Notes spécifiques à des plateformes » ci-dessous pour voir s'il y a des informations spécifiques à votre système d'exploitation, tout particulièrement dans le cas d'un vieux système.
Si vous avez des problèmes d'installation sur une plateforme qui est connue comme étant supportée d'après les récents résultats de la ferme de construction, merci de rapporter cette information à <pgsql-bugs@postgresql.org>. Si vous êtes intéressé pour porter PostgreSQL™ sur une nouvelle plateforme, <pgsql-hackers@postgresql.org> est l'endroit approprié pour en discuter.
Cette section documente des problèmes spécifiques additionnels liés à des plateformes, en ce qui concerne l'installation et le paramétrage de PostgreSQL. Assurez-vous de lire aussi les instructions d'installation, et en particulier Section 1.2, « Prérequis ». Par ailleurs, consultez le fichier src/test/regress/README et la documentation ??? à propos de l'interprétation des tests de régression.
Les plateformes qui ne sont pas traitées ici n'ont pas de problèmes d'installation spécifiques connus.
PostgreSQL fonctionne sur AIX, mais réussir à l'installer correctement peut s'avérer difficile. Les versions AIX de la 4.3.3 à la 6.1 sont considérées comme supportées en théorie. Vous pouvez utiliser GCC ou le compilateur natif IBM xlc. En général, utiliser des versions récentes d'AIX et PostgreSQL rend la tâche plus simple. Vérifiez la ferme de compilation pour avoir des informations à jour sur les versions d'AIX connues pour être compatibles.
Utilisez les options suivantes de configure en plus des vôtres si vous avez installé Readline ou libz à ces endroits : --with-includes=/usr/local/include --with-libraries=/usr/local/lib.
Si vous n'avez pas un PowerPC ou vous utilisez GCC, vous pourriez voir des différences d'arrondi dans les tests de régression géométriques. Il s'agira probablement d'avertissements à propos de division 0.0/0.0 et de symboles dupliqués que vous pourrez ignorer.
Quelques-uns des outils AIX pourraient être « un peu différents » de ce à quoi vous pourriez être accoutumé sur d'autres plateformes. Si vous cherchez une version de ldd, utilisée pour déterminer quel code dépend de quelle bibliothèque, les URL suivantes pourraient vous aider : http://www.faqs.org/faqs/aix-faq/part4/section-22.html, http://www.han.de/~jum/aix/ldd.c.
Tableau 1.1, « Niveaux minimums recommandés de correctifs pour AIX » indique les niveaux minimum de correctifs demandés pour les différentes versions d'AIX. Pour vérifier votre niveau de correctif, utilisez oslevel -r de AIX 4.3.3 à AIX 5.2 ML 7, et oslevel -s pour les versions ultérieures.
Tableau 1.1. Niveaux minimums recommandés de correctifs pour AIX
| Version d'AIX | Niveau du correctif |
|---|---|
| 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 |
Sur AIX 5.3, il y a des problèmes pour compiler et faire fonctionner PostgreSQL avec GCC.
Vous voudrez utiliser une version de GCC supérieure à 3.3.2, en particulier si vous utilisez une version pré-packagée. Nous avons eu de bons résultats avec la 4.0.1. Les problèmes avec les versions précédentes semblent être davantages liées à la façon dont IBM a packagé GCC qu'à des problèmes réels, avec GCC, ce qui fait que si vous compilez GCC vous même, vous pourriez réussir avec une version plus ancienne de GCC.
Dans AIX 5.3, la structure sockaddr_storage n'est pas définie avec une taille suffisante. En version 5.3, IBM a augmenté la taille de sockaddr_un, la structure d'adresse pour une socket de domaine Unix, mais n'a pas augmenté en conséquence la taille de sockaddr_storage. La conséquence est que les tentatives d'utiliser une socket de domaine Unix avec PostgreSQL amènent libpq à dépasser la taille de la structure de données. Les connexions TCP/IP fonctionnent, mais pas les sockets de domaine Unix, ce qui empêche les tests de régression de fonctionner.
Le problème a été rapporté à IBM, et est enregistré en tant que rapport de bogue PMR29657. Si vous mettez à jour vers le niveau de maintenance 5300-03 et ultérieur, le correctif sera inclus. Une résolution immédiate est de corriger _SS_MAXSIZE à 1025 dans /usr/include/sys/socket.h. Dans tous les cas, recompilez PostgreSQL une fois que vous avez l'en-tête corrigé.
PostgreSQL se base sur la fonction système 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 problèmes relatifs à ces paramètres, la mise à jour vers le niveau de correctif approprié indiqué dans Tableau 1.1, « Niveaux minimums recommandés de correctifs pour AIX » pourrait se charger de cela.
Un utilisateur a rapporté :
Lors de l'implémentation de PostgreSQL version 8.1 sur AIX 5.3, nous tombions périodiquement sur des problèmes quand le collecteur de statistiques ne voulait « mystérieusement » pas démarrer. Cela se trouvait être le résultat d'un comportement inattendu dans l'implémentation d'IPv6. Il semble que PostgreSQL et IPv6 ne fonctionnent pas bien ensemble actuellement sur AIX.
Chacune des actions suivantes « corrigent » le problème.
Supprimer l'adresse IPv6 pour localhost :
(as root) # ifconfig lo0 inet6 ::1/0 delete
Supprimer IPv6 des services réseau. Le fichier /etc/netsvc.conf sur AIX est en gros équivalent à /etc/nsswitch.conf sur Solaris/Linux. La valeur par défaut, sur AIX, est donc :
hosts=local,bind
Remplacez ceci avec :
hosts=local4,bind4
pour désactiver la recherche des adresses IPv6.
AIX est particulier dans la façon dont il gère la mémoire. Vous pouvez avoir un serveur avec des gigaoctets de mémoire libre, mais malgré tout avoir des erreurs de mémoire insuffisante ou des erreurs d'espace d'adressage quand vous lancez des applications. Un exemple est createlang qui échoue avec des erreurs inhabituelles. Par exemple, en exécutant en tant que propriétaire de l'installation PostgreSQL :
-bash-3.00$ createlang plpgsql template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the address space for the process.
En l'exécutant en tant que non-propriétaire, mais dans le groupe propriétaire de l'installation PostgreSQL :
-bash-3.00$ createlang plpgsql template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": Bad address
On a un autre exemple avec les erreurs 'out of memory' dans les traces du serveur PostgreSQL, avec toute allocation de mémoire proche ou supérieure 256 Mo qui échoue.
La cause générale de ces problèmes est le nombre de bits et le modèle mémoire utilisé par le processus serveur. Par défaut, tous les binaires compilés sur AIX sont 32-bits. Cela ne dépend pas du matériel ou du noyau en cours d'utilisation. Ces processus 32-bits sont limités à 4 Go de mémoire présentée en segments de 256 Mo utilisant un parmi quelques modèles. Le modèle par défaut permet moins de 256 Mo dans le tas, comme il partage un seul segment avec la pile.
Dans le cas de l'exemple createlang ci-dessus, vérifiez votre umask et les droits des binaires de l'installation PostgreSQL. Les binaires de l'exemple étaient 32-bits et installés en mode 750 au lieu de 755. En raison des droits, seul le propriétaire ou un membre du groupe propriétaire peut charger la bibliothèque. Puisqu'il n'est pas lisible par tout le mode, le chargeur place l'objet dans le tas du processus au lieu d'un segment de mémoire de bibliothèque où il aurait été sinon placé.
La solution « idéale » pour ceci est d'utiliser une version 64-bits de PostgreSQL, mais ce n'est pas toujours pratique, parce que les systèmes équipés de processeurs 32-bits peuvent compiler mais ne peuvent pas exécuter de binaires 64-bits.
Si un binaire 32-bits est souhaité, positionnez LDR_CNTRL à MAXDATA=0xn0000000, où 1<=n <= 8 avant de démarrer le serveur PostgreSQL, et essayez différentes valeurs et paramètres de postgresql.conf pour trouver une configuration qui fonctionne de façon satisfaisante. Cette utilisation de LDR_CNTRL notifie à AIX que vous voulez que le serveur réserve MAXDATA octets pour le tas, alloués en segments de 256 Mo. Quand vous avez trouvé une configuration utilisable, ldedit peut être utilisé pour modifier les binaires pour qu'ils utilisent par défaut la taille de tas désirée. PostgreSQL peut aussi être recompilé, en passant à configure LDFLAGS="-Wl,-bmaxdata:0xn0000000" pour obtenir le même résultat.
Pour une compilation 64-bits, positionnez OBJECT_MODE à 64 et passez CC="gcc -maix64" et LDFLAGS="-Wl,-bbigtoc" à configure. (Les options pour xlc pourraient différer.) Si vous omettez les exports de OBJECT_MODE, votre compilation échouera avec des erreurs de l'éditeur de liens. Quand OBJECT_MODE est positionné, il indique aux outils de compilation d'AIX comme ar, as et ld quel types de fichiers manipuler par défaut.
Par défaut, de la surallocation d'espace de pagination peut se produire. Bien que nous ne l'ayons jamais constaté, AIX tuera des processus quand il se trouvera à court de mémoire et que la zone surallouée est accédée. Le comportement le plus proche de ceci que nous ayons constaté est l'échec de fork parce que le système avait décidé qu'il n'y avait plus de suffisamment de mémoire disponible pour un nouveau processus. Comme beaucoup d'autres parties d'AIX, la méthode d'allocation de l'espace de pagination et le « out-of-memory kill » sont configurables soit pour le système soit pour un processus, si cela devient un problème.
« Large Program Support ». AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
« Program Address Space Overview ». AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
« Performance Overview of the Virtual Memory Manager (VMM) ». AIX Documentation: Performance Management Guide.
« Page Space Allocation ». AIX Documentation: Performance Management Guide.
« Paging-space thresholds tuning ». AIX Documentation: Performance Management Guide.
Developing and Porting C and C++ Applications on AIX. IBM Redbook.
PostgreSQL peut être construit avec Cygwin, un environnement similaire à Linux pour Windows, mais cette méthode est inférieure à la version native Windows (voir ???) et n'est plus recommandée.
Quand vous compilez à partir des sources, suivant la procédure normale d'installation (c'est-à-dire ./configure; make; etc...), notez les différences suivantes spécifiques à Cygwin :
Positionnez le path pour utiliser le répertoire binaire Cygwin avant celui des utilitaires Windows. Cela permettra d'éviter des problèmes avec la compilation.
La commande make GNU est appelée "make", pas "gmake".
La commande adduser n'est pas supportée ; utilisez les outils appropriés de gestion d'utilisateurs sous Windows NT, 2000 ou XP. Sinon, sautez cette étape.
La commande su n'est pas supportée ; utilisez ssh pour simuler la commande su sous Windows NT, 2000 ou XP. Sinon, sautez cette étape.
OpenSSL n'est pas supporté.
Démarrez cygserver pour le support de la mémoire partagée. Pour cela, entrez la commande /usr/sbin/cygserver &. Ce programme doit fonctionner à chaque fois que vous démarrez le serveur PostgreSQL ou que vous initialisez un cluster de bases de données (initdb). La configuration par défaut de cygserver pourrait nécessiter des changements (par exemple, augmenter SEMMNS) pour éviter à PostgreSQL d'échouer en raison d'un manque de ressources système.
Les tests de régression en parallèle (make check) peuvent générer des échecs de tests de régression aléatoires en raison d'un dépassement de capacité de la file d'attente de listen() qui cause des erreurs de connexion refusée ou des blocages. Vous pouvez limiter le nombre de connexion en utilisant la variable de make MAX_CONNECTIONS comme ceci :
make MAX_CONNECTIONS=5 check
(Sur certains systèmes, vous pouvez avoir jusqu'à 10 connexions simultanées).
Il est possible d'installer cygserver et le serveur PostgreSQL en tant que services Windows NT. Pour plus d'informations sur comment le faire, veuillez vous référer au document README inclus avec le package binaire PostgreSQL sur Cygwin. Il est installé dans le répertoire /usr/share/doc/Cygwin.
PostgreSQL 7.3 et plus devraient fonctionner sur les machines PA-RISC Séries 700/800 sous HP-UX 10.X ou 11.X, si les correctifs appropriés sur le système et les outils de compilation sont bien appliqués. Au moins un développeur teste de façon régulière sur HP-UX 10.20, et nous avons des rapports d'installations réussies 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 à partir des sources Git plutôt 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 êtes assez à 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 supérieur, sinon initdb pourrait bloquer :
PHSS_30966 s700_800 ld(1) and linker tools cumulative patch
De façon générale, vous devriez être à 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 http://itrc.hp.com et ftp://us-ffs.external.hp.com/ pour télécharger 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. Des binaires GCC pour HP-UX PA-RISC et Itanium sont disponibles sur http://www.hp.com/go/gcc. N'oubliez pas de récupérer et d'installer les binutils en même temps.
Si vous compilez sur une machine PA-RISC 2.0 et que vous voulez que les binaires compilés fonctionnent sur une machine PA-RISC 1.1, vous devez spécifier +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 dépendent :
PHSS_30848 s700_800 HP C Compiler (A.05.57)
PHSS_30849 s700_800 u2comp/be/plugin library Patch
Si vous avez à la fois le compilateur C HP et celui de GCC, vous voudrez peut être spécifier explicitement le compilateur à utiliser quand vous exécuterez configure :
./configure CC=cc
pour le compilateur HP, ou
./configure CC=gcc
pour GCC. Si vous omettez ce paramètre, configure choisira gcc s'il en a la possibilité.
Le répertoire par défaut d'installation est /usr/local/pgsql, que vous voudrez peut être remplacer par quelque chose dans /opt. Si c'est le cas, utilisez l'option --prefix de configure.
Dans les tests de régression, il pourrait y avoir des différences dans les chiffres les moins significatifs des tests de géométrie, qui varient suivant les versions de compilateur et de bibliothèque mathématique utilisées. Toute autre erreur est suspecte.
PostgreSQL a été rapporté comme fonctionnant correctement sur les processeurs MIPS r8000, r10000 (à la fois ip25 et ip27) et r120000 (ip35), sur IRIX 6.5.5m, 6.5.12, 6.5.13, et 6.5.26 avec les compilateurs MIPSPro de versions 7.30, 7.3.1.2m, 7.3, et 7.4.4m.
Vous aurez besoin du compilateur C ANSI MIPSPro. Il y a des problèmes à la compilation avec GCC. C'est dû à un bogue GCC connu (non corrigé en version 3.0), lié à l'utilisation de fonctions qui retournent certains types de structures. Ce bogue affecte des fonctions telles que inet_ntoa, inet_lnaof, inet_netof, inet_makeaddr, et semctl. Il semblerait qu'on puisse résoudre le problème en forçant les fonctions à l'éditeur de liens avec libgcc, mais ceci n'a pas encore été testé.
Il est connu que la version 7.4.1m du compilateur MIPSPro génère du code incorrect. Le symptôme est « invalid primary checkpoint record » quand on tente de démarrer la base. La version 7.4.4m est OK ; le statut des versions intermédiaires est inconnu.
Il pourrait y avoir un problème de compilation comme celui-ci :
cc-1020 cc: ERROR File = pqcomm.c, Line = 427
The identifier "TCP_NODELAY" is undefined.
if (setsockopt(port->sock, IPPROTO_TCP, TCP_NODELAY,
Certaines versions incluent les définitions TCP dans sys/xti.h, il est alors nécessaire d'ajouter #include <sys/xti.h> dans src/backend/libpq/pqcomm.c et dans src/interfaces/libpq/fe-connect.c. Si vous rencontrez ce problème, merci de nous le faire savoir, afin que nous puissions développer un correctif approprié.
Dans les tests de régression, il pourrait y avoir des différences dans les chiffres les moins significatifs des tests de géométrie, suivant le FPU que vous utilisez. Toute autre erreur est suspecte.
PostgreSQL pour Windows peut être compilé en utilisant MinGW, un environnement de compilation similaire à Unix pour les systèmes d'exploitation Microsoft, ou en utilisant la suite de compilation Visual C++™ de Microsoft. La variante de compilation MinGW utilise le système de compilation normal décrit dans ce chapitre ; la compilation via Visual C++ fonctionne de façon totalement différente et est décrite dans la documentation???. C'est une compilation totalement native qui n'utilise aucun logiciel supplémentaire comme MinGW. Un installeur est disponible sur le serveur web officiel de PostgreSQL.
Le port natif Windows requiert un système Microsoft 200 ou ultérieurs, 32 bits ou 64 bits. Les systèmes plus anciens n'ont pas l'infrastructure nécessaire (mais Cygwin peut être utilisé pour ceux-ci). MinGW, le système de compilation similaire à Unix, et MSYS, une suite d'outils Unix nécessaires pour exécuter des scripts shell tels que configure, peuvent être téléchargés de http://www.mingw.org/. Aucun de ces outils n'est nécessaire pour exécuter les binaires générés ; ils ne sont nécessaires que pour créer les binaires.
Après que vous ayez tout installé, il est suggéré que vous lanciez psql dans CMD.EXE, car la console MSYS a des problèmes de tampons.
PostgreSQL peut être compilé sur SCO UnixWare 7 et SCO OpenServer 5. Sur OpenServer, vous pouvez utiliser soit l'OpenServer Development Kit soit l'Universal Development Kit. Toutefois, quelques ajustements peuvent être nécessaires, comme décrit ci-dessous.
Vous aurez besoin de votre copie du CD SCO Skunkware. Le CD Skunkware est inclus avec UnixWare 7 et les versions actuelles d'OpenServer 5. Skunkware inclut des versions prêtes à l'installation de nombreux programmes populaires qui sont disponibles sur Internet. Par exemple, sont inclus gzip, gunzip, GNU Make, Flex et Bison. Pour UnixWare 7.1, ce CD est maintenant appelé « Open License Software Supplement ». Si vous n'avez pas ce CD, les logiciels qu'il contient sont disponibles sur le serveur FTP anonyme http://www.sco.com/skunkware/.
Les versions de Skunkware sont différentes entre UnixWare et OpenServer. Faites attention à installer la version correcte pour votre système d'exploitation, sauf pour les cas notifiés ci-dessous.
Sous UnixWare 7.1.3 et supérieur, le compilateur GCC est inclus sur le CD UDK, ainsi que GNU Make.
Vous devez utiliser le programme GNU Make, qui est inclus sur le CD Skunkware. Par défaut, il s'installe en tant que /usr/local/bin/make. Pour éviter la confusion avec le programme make SCO, vous pouvez renommer GNU make en gmake.
À partir d'UnixWare 7.1.3, le programme GNU Make est dans la portion OSTK du CD UDK, et est dans /usr/gnu/bin/gmake.
La bibliothèque Readline est disponible sur le CD Skunkware, mais pas sur le CD Skunkware d'UnixWare 7.1. Si vous avez UnixWare 7.0.0 ou 7.0.1, vous pouvez installer à partir du CD, sinon essayez ftp://ftp.sco.com/skunkware.
Par défaut, Readline s'installe dans /usr/local/lib et /usr/local/include. Toutefois, le programme configure de PostgreSQL ne la trouvera pas là sans aide. Si vous avez installé Readline, alors utilisez les options suivantes avec configure :
./configure --with-libraries=/usr/local/lib --with-includes=/usr/local/include
Si vous utilisez le nouveau compilateur Universal Development Kit (UDK) avec OpenServer, vous devez spécifier l'emplacement des bibliothèques UDK :
./configure --with-libraries=/udk/usr/lib --with-includes=/udk/usr/include
Ajouté aux options Readline précédentes, cela donne :
./configure --with-libraries="/udk/usr/lib /usr/local/lib" --with-includes="/udk/usr/include /usr/local/include"
Par défaut, les man pages PostgreSQL sont installées dans /usr/local/pgsql/man. Par défaut, UnixWare ne recherche pas de man pages à cet endroit. Pour pouvoir les lire, vous devez modifier la variable MANPATH pour y inclure /etc/default/man, par exemple :
MANPATH=/usr/lib/scohelp/%L/man:/usr/dt/man:/usr/man:/usr/share/man:scohelp:/usr/local/man:/usr/local/pgsql/man
Sur OpenServer, un effort supplémentaire devra être fait pour rendre les man pages utilisables, parce que le système man est un peu différent de celui des autres plateformes. À l'heure actuelle, PostgreSQL ne les installera pas du tout.
Pour les compilateurs antérieurs à celui fourni avec OpenUNIX 8.0.0 (UnixWare 7.1.2), dont celui du 7.1.1b Feature Supplement, vous pourriez avoir besoin de spécifier -Xb dans CFLAGS ou la variable d'environnement CC. Ce qui l'annonce est une erreur dans la compilation de tuplesort.c, sur les fonctions inline. Apparemment, il y a eu un changement dans le compilateur 7.1.2 (8.0.0) et les suivants.
PostgreSQL est bien supporté sous Solaris. Plus le système d'exploitation est à jour, moins de problèmes vous aurez ; les détails sont ci-dessous.
Notez que PostgreSQL est fourni avec Solaris 10 (à partir de l'update 2). Des packages officiels sont aussi disponibles sur http://pgfoundry.org/projects/solarispackages/. Des packages pour des versions plus anciennes de Solaris peuvent aussi être obtenus sur http://www.sunfreeware.com/ ou http://www.blastwave.org/.
Vous pouvez compiler soit avec GCC, soit avec le compilateur de Sun. Pour une meilleure optimisation du code, le compilateur de Sun est fortement recommandé sur l'architecture SPARC. Il y a eu des problèmes rapportés à l'utilisation de GCC 2.95.1 ; des versions de gcc 2.95.3 ou supérieure sont recommandées. Si vous utilisez le compilateur de Sun, attention à ne pas sélectionner /usr/ucb/cc ; utilisez /opt/SUNWspro/bin/cc.
Vous pouvez télécharger Sun Studio sur http://developers.sun.com/sunstudio/downloads/. De nombreux outils GNU sont intégrés dans Solaris 10, ou sont présents 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 ou http://www.blastwave.org. Si vous préférez les sources, allez sur http://www.gnu.org/order/ftp.html.
Quand vous compilez PostgreSQL avec le support OpenSSL, vous pourriez rencontrer des erreurs de compilation dans les fichiers suivants :
src/backend/libpq/crypt.c
src/backend/libpq/password.c
src/interfaces/libpq/fe-auth.c
src/interfaces/libpq/fe-connect.c
C'est en raison d'un conflit d'espace de nom entre l'en-tête standard /usr/include/crypt.h et les fichiers d'en-tête fournis par OpenSSL.
La mise à jour de l'installation d'OpenSSL vers la version 0.9.6a résout ce problème. Solaris 9 et supérieurs ont une version plus récente d'OpenSSL.
Si configure se plaint d'un programme de test en échec, c'est probablement un cas de l'éditeur de lien à l'exécution qui ne trouve pas une bibliothèque, probablement libz, libreadline ou une autre bibliothèque non standard telle que libssl. Pour 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(1) pour plus d'informations.
Dans Solaris 7 et précédentes, la version 64 bits de la libc a une routine vsnprintf boguée, qui génère des « core dumps » aléatoires dans PostgreSQL. Le contournement le plus simple connu est de forcer PostgreSQL à utiliser sa propre version de vsnprintf plutôt que celle de la bibliothèque. Pour faire ceci, après avoir exécuté configure, éditez 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 déjà listés dans cette variable. L'ordre est sans importance.) Puis compilez comme d'habitude.
Sur l'architecture SPARC, Sun Studio est fortement recommandé pour la compilation. Essayez d'utiliser l'option d'optimisation -xO5 pour générer des binaires sensiblement plus rapides. N'utilisez pas d'options qui modifient le comportement des opérations à 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, préférez la version 32 bits. Les opérations et les binaires 64 bits sont plus lents que les variantes 32 bits. D'un autre côté, le code 32 bits sur un processeur de la famille AMD64 n'est pas natif, ce qui fait que le code 32 bits est significativement plus lent sur cette famille de processeurs.
Des astuces pour optimiser les performances de PostgreSQL sur Solaris peuvent être trouvées sur http://www.sun.com/servers/coolthreads/tnb/applications_postgresql.jsp. Cet article se focalise principalement sur la plateforme T2000, mais beaucoup des recommandations sont aussi utiles avec d'autres plateformes sous Solaris.
Oui, l'utilisation de DTrace est possible. Voir la documentation ??? pour davantage d'informations. Vous pouvez aussi trouver plus d'informations dans cet article : http://blogs.sun.com/robertlor/entry/user_level_dtrace_probes_in.
Si vous voyez l'édition de liens de l'exécutable postgres échouer avec un message d'erreur similaire à
Undefined first referenced symbol in file AbortTransaction utils/probes.o CommitTransaction utils/probes.o ld: fatal: Symbol referencing errors. No output written to postgres collect2: ld returned 1 exit status gmake: *** [postgres] Error 1
l'installation DTrace est trop ancienne pour gérer les sondes dans les fonctions statiques. Solaris 10u4 ou plus récent est nécessaire.