Ce document décrit l'installation de PostgreSQL™ à partir du code source (si vous installez une distribution préparée, tels qu'un paquetage RPM ou Debian, vous pouvez ignorer ce document et lire à la place les instructions du mainteneur du paquetage).
./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 est la version longue.
En général, les plateformes style unix modernes doivent être capables d'exécuter PostgreSQL™. Les plateformes sur lesquelles des tests ont été effectuées sont listées dans la Section 1.8, « 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 que vous pouvez consulter si vous avez des problèmes.
Les logiciels suivants sont nécessaires pour compiler PostgreSQL™ :
GNU make est nécessaire ; les autres programmes make ne devraient pas fonctionner. GNU make est souvent installé sous le nom gmake ; ce document fera toujours référence à lui sous ce nom (sur certains système, GNU make est l'outil par défaut et est nommé make). Pour savoir quelle version vous utilisez, saisissez
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. 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 avec soit gzip soit bzip2.
La bibliothèque GNU Readline™ est utilisée par défaut (pour une édition facile des lignes et une recherche de l'historique des commandes). Si vous ne voulez pas l'utiliser, il vous faut spécifier --without-readline au moment d'exécuter 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. Si vous utilisez une distribution Linux basée sur des paquetages, faites attention au fait que vous aurez besoin à la fois des paquetages readline et readline-devel s'ils sont séparés dans votre distribution.
La bibliothèque de compression zlib™ sera utilisée par défaut. Si vous ne voulez pas l'utiliser, alors vous devez spécifier l'option --without-zlib à configure. Utiliser cette option désactive le support des archives compressées dans pg_dump et pg_restore.
Des logiciels supplémentaires sont nécessaires pour construire PostgreSQL™ sur Windows™. Vous pouvez construire PostgreSQL™ pour les versions NT™ de Windows™ (comme Windows XP et 2003) en utilisant MinGW™ ; voir doc/FAQ_MINGW pour les détails. Vous pouvez aussi construire PostgreSQL™ en utilisant Cygwin™ ; voir doc/FAQ_CYGWIN. Une construction basée sur Cygwin™ fonctionnera sur les anciennes versions de Windows™ mais, si vous avez le choix, nous vous recommandons l'approche de MinGW™. Bien qu'il soit le seul ensemble d'outils recommandé pour une construction complète, il est possible de construire seulement la bibliothèque cliente C (libpq) et le terminal interactif (psql) en utilisant d'autres environnements de développement sous Windows™. Pour des détails, voir le le chapitre «Installation sur Windows™ du seul client » de la documentation.
Les paquetages suivants sont optionnels. Ils ne sont pas obligatoires pour une compilation par défaut mais le sont lorsque certaines options sont utilisées ainsi que c'est expliqué par la suite.
Pour installer le langage de procédures PL/Perl, vous devez avoir une installation de Perl™ complète, comprenant la bibliothèque libperl et les fichiers d'en-tête. Comme PL/Perl est une bibliothèque partagée, la bibliothèque libperl doit aussi être partagée sur la plupart des plateformes. Ce qui n'est le cas que dans les versions récentes de Perl™ et, dans tous les cas, c'est le choix de ceux qui installent 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 vous n'avez pas de bibliothèque partagée alors qu'il vous en faut une, un message tel que celui-ci apparaîtra durant la compilation pour vous en avertir :
*** 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 vous ne suivez pas la sortie écran, vous pourrez constater que la bibliothèque plperl.so de PL/Perl, ou similaire, n'est pas installée.) Si c'est le cas, il vous faudra recompiler et ré-installer Perl™ manuellement pour être capable de compiler PL/Perl. Lors de la phase de configuration de Perl™, demandez que les bibliothèques soient partagées.
Pour compiler le langage de procédures 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™ auront besoin de l'installer.
Puisque PL/Python devra ê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 pour une installation par défaut de Python. Si, après la compilation et l'installation, vous avez un fichier nommé plpython.so (des extensions différentes sont possibles), alors tout va pour le mieux. Sinon, vous devriez avoir vu un avertissement semblable à :
*** 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 que vous devez recompiler Python™ (ou une partie) pour activer cette bibliothèque partagée.
Si vous avez des problèmes, lancez le configure de Python™ 2.3 ou d'une version suivante en utilisant le commutateur --enable-shared. Sur certains systèmes d'exploitation, vous n'avez pas besoin de construire une bibliothèque partagée mais vous devrez convaincre le système de construction de PostgreSQL™ sur ce point. Consultez le fichier Makefile dans le répertoire src/pl/plpython pour des détails supplémentaires.
Si vous voulez construire le langage de procédure PL/Tcl, vous avez besoin que Tcl soit installé.
Pour activer le support de langage natif (NLS), qui permet d'afficher les messages dans une langue autre que l'anglais, vous avez besoin d'une implémentation de l'API Gettext. Certains systèmes d'exploitation l'ont intégré (par exemple, Linux, NetBSD, Solaris). Pour les autres systèmes, vous pouvez télécharger les paquetages nécessaires sur http://developer.postgresql.org/~petere/bsd-gettext. Si vous utilisez l'implémentation de Gettext des bibliothèques C GNU, vous devrez en plus utiliser le paquetage GNU Gettext™ pour certains utilitaires. Pour toutes les autres implémentations, vous n'en avez pas besoin.
Kerberos, OpenSSL™, OpenLDAP™ ou PAM si vous voulez une authentification ou un chiffrement en utilisant ces services.
Si vous compilez à partir d'une arborescence Git™ au lieu d'utiliser un paquetage contenant les sources, ou si vous faites du développement au niveau serveur, vous aurez aussi besoin des paquetages suivants :
GNU Flex et Bison sont nécessaires pour compiler à partir d'une récupération du Git ou si vous modifiez les fichiers de recherche et d'analyse. Si vous en avez besoin, vérifiez que vous avez Flex 2.5.4 ou postérieur et Bison 1.875 ou postérieur. D'autres programmes yacc peuvent parfois d'être utilisés, ce qui n'est pas recommandé vu les efforts supplémentaires que cela demande. D'autres programmes lex ne fonctionneront définitivement pas.
Si vous avez besoin de paquetages GNU, vous pourrez les trouver sur un site miroir de GNU (voir http://www.gnu.org/order/ftp.html pour en avoir la liste) ou sur ftp://ftp.gnu.org/gnu/.
Vérifiez aussi que vous avez assez d'espace disque de disponible. Il vous faudra 65 Mo pour l'espace de compilation et 15 Mo pour le répertoire d'installation. Une base de données vide en cluster nécessite 25 Mo, les fichiers de la base prenant cinq fois plus d'espace que des fichiers texte contenant les mêmes données. Si vous voulez faire des tests de régression, vous aurez besoin temporairement de 90 Mo supplémentaires. Utilisez la commande df pour vérifier l'espace disque.
Le format de stockage interne des données a changé avec cette nouvelle version de PostgreSQL™. Toutefois, si vous faites une mise à jour qui n'a pas un numéro de version de la forme « 8.2.x », vous devrez faire une sauvegarde et une restauration des données ainsi que c'est montré ici. Les instructions considèrent que votre installation existante est dans le répertoire /usr/local/pgsql et que la zone de données est dans /usr/local/pgsql/data. Remplacez les chemins de façon approprié.
Assurez-vous que vos données ne sont pas mises à jour pendant ou après la sauvegarde. Cela n'affecterait en rien l'intégrité de la sauvegarde mais les données modifiées ne seraient pas incluses. Si nécessaire, éditez le fichier /usr/local/pgsql/data/pg_hba.conf (ou équivalent) pour verrouiller tous les accès sauf les vôtres.
Pour effectuer une sauvegarde de votre base, saisissez :
pg_dumpall > fichierdesortie
Si vous souhaitez conserver les identifiants d'objets (lorsqu'ils sont utilisés comme clé étrangère), utilisez l'option -o lors de l'exécution de pg_dumpall.
Pour effectuer une sauvegarde, vous pouvez exécuter la commande pg_dumpall incluse dans la distribution de votre version actuelle. Cependant, pour de meilleurs résultats, essayez d'utiliser la commande pg_dumpall contenue dans PostgreSQL™ 8.2.23 puisqu'elle corrige les erreurs des versions précédentes. Ce conseil est absurde tant que vous n'avez pas encore installé la nouvelle version. Il devient valable si vous souhaitez installer la nouvelle version en parallèle. Dans ce cas, vous pouvez faire l'installation normalement et ne transférer les données qu'après, ce qui réduira le temps d'indisponibilité.
Si vous installez la nouvelle version à la place de l'ancienne, arrêtez l'ancien serveur, au plus tard avant d'installer les nouveaux fichiers :
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, la commande
/etc/rc.d/init.d/postgresql stop
devrait fonctionner. Une autre possibilité est pg_ctl stop.
Si vous faites l'installation au même endroit que l'ancienne, il peut être une bonne idée de déplacer l'ancienne version au cas où vous auriez des problèmes et que vous ayez besoin de revenir en arrière. Utilisez une commande telle que :
mv /usr/local/pgsql /usr/local/pgsql.old
Après l'installation de PostgreSQL™ 8.2.23, créez un répertoire pour les données et démarrez le nouveau serveur. Rappelez-vous que vous devez exécuter ces commandes en étant connecté avec l'utilisateur dédié à la base (qui doit déjà exister si vous changez juste de version).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Enfin, restaurez vos données avec
/usr/local/pgsql/bin/psql -d postgres -f outputfile
en utilisant le nouveau psql.
Des informations supplémentaires apparaissent dans la documentation que vous êtes encouragés à lire dans tous les cas.
Configuration
La première étape de la procédure d'installation est de configurer votre arborescence système et de choisir les options qui vous intéressent. Ce qui est fait en exécutant le script configure. Pour une installation par défaut, entrez 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 à votre système d'exploitation. Il créera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a été trouvé (vous pouvez aussi exécuter configure à partir d'un répertoire hors de l'arborescence des sources si vous voulez 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.
Vous pouvez personnaliser les processus de compilation et d'installation en mettant 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és sous PREFIX.
Si vous avez des besoins spécifiques, vous pouvez personnaliser les sous-répertoires à l'aide des options suivantes. Néanmoins, si vous les laissez vide avec leurs valeurs par défaut, l'installation sera déplaçable, ce qui signifie que vous pourrez bouger le répertoire après installation (les emplacements de man et doc ne sont pas affectés par ceci).
Pour les installations déplaçables, vous pourriez vouloir utiliser l'option --disable-rpath de configure. De plus, vous aurez besoin d'indiquer au système d'exploitation comment trouver les bibliothèques partagées.
Vous pouvez installer les fichiers dépendants de l'architecture dans un répertoire différent, EXEC-PREFIX, de celui donné par PREFIX. Ce qui peut être utile pour partager les fichiers dépendants de l'architecture entre plusieurs machines. Si vous l'omettez, EXEC-PREFIX est égal à PREFIX et les fichiers dépendants seront installés sous la même arborescence que les fichiers indépendants de l'architecture, ce qui est probablement ce que vous voulez.
Spécifie le répertoire des exécutables. Par défaut, il s'agit de EXEC-PREFIX/bin, ce qui signifie /usr/local/pgsql/bin.
Prépare le répertoire pour des fichiers de données en lecture seule utilisés par les programmes d'installation. Par défaut, il s'agit de PREFIX/share. Il est bon de noter que cela n'a rien à voir avec l'emplacement des fichiers de votre base de données.
Le répertoire contenant divers fichiers de configuration. Par défaut, il s'agit de PREFIX/etc.
L'endroit où installer les bibliothèques et les modules chargeables dynamiquement. Par défaut, il s'agit de EXEC-PREFIX/lib.
Le répertoire où sont installées les en-têtes C et C++. Par défaut, il s'agit de PREFIX/include.
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 PREFIX/man.
Les fichiers de documentation, sauf les pages « man », seront installés dans ce répertoire. Par défaut, il s'agit de PREFIX/doc. Si l'option --without-docdir est spécifiée, la documentation ne sera pas installée par make install. Ceci est fait pour aider les scripts d'empaquetage ayant des méthodes particulières pour installer la documentation.
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é au répertoire 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 vous choisissez /usr/local 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 propres par rapport aux 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 (:). Vous aurez probablement à utiliser cette option (et l'option correspondante --with-includes) si vous avez des paquetages installés dans des répertoires non conventionnels.
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. LANGUE est une liste de codes des langues que vous voulez supporter séparés par un espace. Par exemple, --enable-nls='de fr' (l'intersection entre votre liste et l'ensemble des langues traduites actuellement sera calculée automatiquement). Si vous ne spécifiez pas de liste, alors toutes les traductions disponibles seront installées.
Pour utiliser cette option, vous avez besoin d'une implémentation de l'API Gettext ; 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, si vous le faites ici, alors 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 que vous souhaitez exécuter 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 vous voulez utiliser une version différente de Tcl, vous pouvez spécifier le répertoire où le trouver.
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. postgres est pris par défaut. Il n'y a habituellement pas de raison de le changer.
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). Sur Unix, cela requiert l'installation du paquet OpenLDAP™. 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. Sur Windows, la bibliothèque WinLDAP™ est utilisée par défaut.
É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 le stockage des entiers sur 64 bits pour les types datetime et interval plutôt que le stockage par défaut en virgule flottante. Ceci réduit le nombre de valeurs représentatives mais garantit une précision à la microseconde sur toute l'échelle de valeurs (voir la la documentation sur les types de données date et heure pour plus d'informations). Notez aussi que le code de datetime au format entier est plus récent que celui au format en virgule flottante et que nous découvrons encore des bogues de temps en temps.
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.
É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.
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 ralentissent 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. Actuellement, 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 avec le support de l'outil de trace dynamique, DTrace. Le seul système d'exploitation supportant DTrace pour l'instant est Solaris.
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.
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.
Vous pouvez spécifier les variables d'environnement 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 :
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
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.
programme Yacc (bison -y si utilisation de Bison)
Compilation
Pour démarrer la compilation, saisissez
gmake
(Rappelez-vous d'utiliser GNU make). La compilation peut prendre entre cinq minutes et une demi-heure en fonction 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 compileé 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 contiennent 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.3, « Si vous effectuez une 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.
Ménage : Après l'installation, vous pouvez faire le ménage 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.
L'étape 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.
La communauté de développeurs a vérifié que PostgreSQL™ fonctionne sur les plateformes listées ci-après. Dire qu'une plateforme est supportée signifie en général que la compilation et l'installation de PostgreSQL™ peuvent s'exécuter en suivant les instructions et que les tests de régression sont valides. Les entrées « Ferme de construction » font référence aux machines de tests actives dans la ferme de construction PostgreSQL (PostgreSQL Ferme de construction). Les entrées de plateformes affichant une version plus ancienne de PostgreSQL sont celles qui n'ont pas reçu de tests explicites au moment de la sortie de la version 8.2 mais qui doivent toujours fonctionner.
Si vous avez des problèmes avec une installation sur une plateforme supportée, veuillez écrire à <pgsql-bogues@postgresql.org> et non aux personnes listées dans ce document.
| Système d'exploitation | Processeur | Version | Date du rapport | Remarques |
|---|---|---|---|---|
| AIX | PowerPC | 8.2.0 | Fermes de construction grebe (5.3, gcc 4.0.1) ; kookaburra (5.2, cc 6.0) ; asp (5.2, gcc 3.3.2) | Voir doc/FAQ_AIX, tout particulièrement si vous utilisez AIX 5.3 ML3 |
| AIX | RS6000 | 8.0.0 | Hans-Jürgen Schönig (<hs@cybertec.at>), 2004-12-06 | Voir doc/FAQ_AIX |
| BSD/OS | x86 | 8.1.0 | Bruce Momjian (<pgman@candle.pha.pa.us>), 2005-10-26 | 4.3.1 |
| Debian GNU/Linux | Alpha | 8.2.0 | Ferme de construction hare (3.1, gcc 3.3.4) | |
| Debian GNU/Linux | AMD64 | 8.2.0 | Fermes de construction shad (4.0, gcc 4.1.2); kite (3.1, gcc 4.0); panda (sid, gcc 3.3.5) | |
| Debian GNU/Linux | ARM | 8.2.0 | Ferme de construction penguin (3.1, gcc 3.3.4) | |
| Debian GNU/Linux | Athlon XP | 8.2.0 | Ferme de construction rook (3.1, gcc 3.3.5) | |
| Debian GNU/Linux | IA64 | 8.2.0 | Ferme de construction dugong (unstable, icc 9.1.045) | |
| Debian GNU/Linux | m68k | 8.0.0 | Noèl Köthe (<noel@debian.org>), 2004-12-09 | sid |
| Debian GNU/Linux | MIPS | 8.2.0 | Ferme de construction otter (3.1, gcc 3.3.4) | |
| Debian GNU/Linux | MIPSEL | 8.2.0 | Fermes de construction lionfish (3.1, gcc 3.3.4); corgi (3.1, gcc 3.3.4) | |
| Debian GNU/Linux | PA-RISC | 8.2.0 | Fermes de construction manatee (3.1, gcc 4.0.1); kingfisher (3.1, gcc 3.3.5) | |
| Debian GNU/Linux | PowerPC | 8.0.0 | Noèl Köthe (<noel@debian.org>), 2004-12-15 | sid |
| Debian GNU/Linux | Sparc | 8.1.0 | Ferme de construction dormouse (3.1, gcc 3.2.5; 64-bit) | |
| Debian GNU/Linux | x86 | 8.2.0 | Ferme de construction wildebeest (3.1, gcc 3.3.5) | |
| Fedora Linux | AMD64 | 8.2.0 | Fermes de construction impala (FC6, gcc 4.1.1); bustard (FC5, gcc 4.1.0); wasp (FC5, gcc 4.1.0); viper (FC3, gcc 3.4.4) | |
| Fedora Linux | PowerPC | 8.2.0 | Ferme de construction sponge (FC5, gcc 4.1.0) | |
| Fedora Linux | x86 | 8.2.0 | Fermes de construction agouti (FC5, gcc 4.1.1); thrush (FC1, gcc 3.3.2) | |
| FreeBSD | AMD64 | 8.2.0 | Fermes de construction platypus (6, gcc 3.4.4); dove (6.1, gcc 3.4.4); ermine (6.1, gcc 3.4.4) | |
| FreeBSD | x86 | 8.2.0 | Fermes de construction minnow (6.1, gcc 3.4.4); echidna (6, gcc 3.4.2); herring (6, Intel cc 7.1) | |
| Gentoo Linux | AMD64 | 8.1.0 | Ferme de construction caribou (2.6.9, gcc 3.3.5) | |
| Gentoo Linux | IA64 | 8.2.0 | Ferme de construction stoat (2.6, gcc 3.3) | |
| Gentoo Linux | PowerPC 64 | 8.2.0 | Ferme de construction cobra (1.4.16, gcc 3.4.3) | |
| Gentoo Linux | x86 | 8.2.0 | Ferme de construction mongoose (1.6.14, icc 9.0.032) | |
| HP-UX | IA64 | 8.2.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2006-10-23 | 11.23, gcc et cc ; voir doc/FAQ_HPUX |
| HP-UX | PA-RISC | 8.2.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2006-10-23 | 10.20 and 11.23, gcc et cc ; voir doc/FAQ_HPUX |
| IRIX | MIPS | 8.1.0 | Kenneth Marshall (<ktm@is.rice.edu>), 2005-11-04 | 6.5, cc seulement |
| Kubuntu Linux | AMD64 | 8.2.0 | Ferme de construction rosella (5.10 « Breezy », gcc 4.0) | |
| Mac OS X | PowerPC | 8.2.0 | Ferme de construction tuna (10.4.2, gcc 4.0) | |
| Mac OS X | x86 | 8.2.0 | Ferme de construction jackal (10.4.8, gcc 4.0.1) | |
| Mandriva Linux | x86 | 8.2.0 | Ferme de construction gopher (Mandriva 2006, gcc 4.0.1) | |
| NetBSD | m68k | 8.2.0 | Ferme de construction osprey (2.0, gcc 3.3.3) | |
| NetBSD | x86 | 8.2.0 | Fermes de construction gazelle (3.0, gcc 3.3.3) ; canary (1.6, gcc 2.95.3) | |
| OpenBSD | AMD64 | 8.2.0 | Ferme de construction zebra (4.0, gcc 3.3.5) | |
| OpenBSD | Sparc | 8.0.0 | Chris Mair (<list@1006.org>), 2005-01-10 | 3.3 |
| OpenBSD | Sparc64 | 8.2.0 | Ferme de construction spoonbill (3.9, gcc 3.3.5) | |
| OpenBSD | x86 | 8.2.0 | Fermes de construction emu (4.0, gcc 3.3.5) ; guppy (3.8, gcc 3.3.5) | minor ecpg test failure on 3.8 |
| Red Hat Linux | AMD64 | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Red Hat Linux | IA64 | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Red Hat Linux | PowerPC | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Red Hat Linux | PowerPC 64 | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Red Hat Linux | S/390 | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Red Hat Linux | S/390x | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Red Hat Linux | x86 | 8.1.0 | Tom Lane (<tgl@sss.pgh.pa.us>), 2005-10-23 | RHEL 4 |
| Slackware Linux | x86 | 8.1.0 | Sergey Koposov (<math@sai.msu.ru>), 2005-10-24 | 10.0 |
| Solaris | Sparc | 8.2.0 | Ferme de construction hyena (Solaris 10, gcc 3.4.3) | Voir doc/FAQ_Solaris |
| Solaris | x86 | 8.2.0 | Ferme de construction dragonfly (Solaris 9, gcc 3.2.3); kudu (Solaris 9, cc 5.3) | Voir doc/FAQ_Solaris |
| SUSE Linux | AMD64 | 8.1.0 | Josh Berkus (<josh@agliodbs.com>), 2005-10-23 | SLES 9.3 |
| SUSE Linux | IA64 | 8.0.0 | Reinhard Max (<max@suse.de>), 2005-01-03 | SLES 9 |
| SUSE Linux | PowerPC | 8.0.0 | Reinhard Max (<max@suse.de>), 2005-01-03 | SLES 9 |
| SUSE Linux | PowerPC 64 | 8.0.0 | Reinhard Max (<max@suse.de>), 2005-01-03 | SLES 9 |
| SUSE Linux | S/390 | 8.0.0 | Reinhard Max (<max@suse.de>), 2005-01-03 | SLES 9 |
| SUSE Linux | S/390x | 8.0.0 | Reinhard Max (<max@suse.de>), 2005-01-03 | SLES 9 |
| SUSE Linux | x86 | 8.0.0 | Reinhard Max (<max@suse.de>), 2005-01-03 | 9.0, 9.1, 9.2, SLES 9 |
| Tru64 UNIX | Alpha | 8.1.0 | Honda Shigehiro (<fwif0083@mb.infoweb.ne.jp>), 2005-11-01 | 5.0, cc 6.1-011 |
| Ubuntu Linux | x86 | 8.2.0 | Ferme de construction caracara (6.06, gcc 4.0.3) | |
| UnixWare | x86 | 8.2.0 | Ferme de construction warthog (7.1.4, cc 4.2) | Voir doc/FAQ_SCO |
| Windows | x86 | 8.2.0 | Fermes de construction yak (XP SP2, gcc 3.4.2) ; bandicoot (Windows 2000 Pro, gcc 3.4.2) ; snake (Windows Server 2003 SP1, gcc 3.4.2) ; trout (Windows Server 2000 SP4, gcc 3.4.2) | Voir doc/FAQ_MINGW |
| Windows with Cygwin | x86 | 8.2.0 | Ferme de construction eel (W2K Server SP4, gcc 3.4.4) | Voir doc/FAQ_CYGWIN |
| Yellow Dog Linux | PowerPC | 8.1.0 | Ferme de construction carp (4.0, gcc 3.3.3) |
Plateformes non supportées : Les plateformes suivantes fonctionnaient mais n'ont pas été testées récemment. Nous les plaçons ici afin de vous prévenir qu'elles peuvent être supportées avec quelques efforts.
| Système d'exploitation | Processeur | Version | Date du rapport | Remarques |
|---|---|---|---|---|
| Debian GNU/Linux | S/390 | 7.4 | Noèl Köthe (<noel@debian.org>), 2003-10-25 | |
| FreeBSD | Alpha | 7.4 | Peter Eisentraut (<peter_e@gmx.net>), 2003-10-25 | 4.8 |
| Linux | PlayStation 2 | 8.0.0 | Chris Mair (<list@1006.org>), 2005-01-09 | requiert --disable-spinlocks (fonctionne mais lentement) |
| NetBSD | Alpha | 7.2 | Thomas Thai (<tom@minnesota.com>), 2001-11-20 | 1.5W |
| NetBSD | arm32 | 7.4 | Patrick Welche (<prlw1@newn.cam.ac.uk>), 2003-11-12 | 1.6ZE/acorn32 |
| NetBSD | MIPS | 7.2.1 | Warwick Hunter (<whunter@agile.tv>), 2002-06-13 | 1.5.3 |
| NetBSD | PowerPC | 7.2 | Bill Studenmund (<wrstuden@netbsd.org>), 2001-11-28 | 1.5 |
| NetBSD | Sparc | 7.4.1 | Peter Eisentraut (<peter_e@gmx.net>), 2003-11-26 | 1.6.1, 32-bit |
| NetBSD | VAX | 7.1 | Tom I. Helbekkmo (<tih@kpnQwest.no>), 2001-03-30 | 1.5 |
| SCO OpenServer | x86 | 7.3.1 | Shibashish Satpathy (<shib@postmark.net>), 2002-12-11 | 5.0.4, gcc ; voir aussi doc/FAQ_SCO |
| SunOS 4 | Sparc | 7.2 | Tatsuo Ishii (<t-ishii@sra.co.jp>), 2001-12-04 |