Ce document chapitre 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 chapitre 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 chapitre 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.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 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.
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 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�. Si vous utilisez une version ant�rieure � la version 8.4 de Tcl™, assurez-vous 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 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 CVS au lieu d'utiliser un paquetage contenant les sources, ou si vous faites du d�veloppement, vous aurez aussi besoin des paquetages suivants :
GNU Flex et Bison sont n�cessaires pour compiler � partir d'une r�cup�ration du CVS 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.
Les sources de PostgreSQL™ 8.3.1 peuvent �tre obtenues par ftp anonyme � ftp://ftp.postgresql.org/pub/source/v8.3.1/postgresql-8.3.1.tar.gz. D'autres options de t�l�chargement sont possibles � partir de notre site web : http://www.postgresql.org/download/. Apr�s avoir obtenu le fichier, d�compressez-le :
gunzip postgresql-8.3.1.tar.gz tar xf postgresql-8.3.1.tar
Cela cr�era un r�pertoire postgresql-8.3.1 contenant les sources de PostgreSQL™ dans le r�pertoire courant. Allez dans ce nouveau r�pertoire pour continuer la proc�dure d'installation.
Ces instructions supposent que votre installation existante se trouve dans le r�pertoire /usr/local/pgsql, et que l'aire de donn�es est dans /usr/local/pgsql/data. Modifiez les chemins de fa�on appropri�.
Le format de stockage interne des donn�es change typiquement � chaque version majeure de PostgreSQL™. Du coup, si vous mettez � jour une installation existante qui n'a pas le num�ro de version ��8.3.x��, vous devez sauvegarder et restaurer vos donn�es. Si vous mettez � jour � partir de PostgreSQL™ ��8.3.x��, la nouvelle version peut utiliser vos fichiers de donn�es actuels, donc vous pouvez ignorer les �tapes de sauvegarde et de restauration ci-dessous parce qu'elles sont inutiles.
Dans le cas de la r�alisation d'une sauvegarde, assurez-vous que votre base de donn�es est en cours de mise � jour. Ceci n'affecte pas l'int�grit� de la sauvegarde mais les donn�es modifi�es seraient bien s�r non inclus. Si n�cessaire, �ditez les droits dans le fichier /usr/local/pgsql/data/pg_hba.conf (ou son �quivalent) pour interdire l'acc�s � tous sauf vous.
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.3.1 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�.
Arr�tez 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, la commande
/etc/rc.d/init.d/postgresql stop
devrait fonctionner. Une autre possibilit� est pg_ctl stop.
En cas de restauration d'une sauvegarde, renommer ou supprimer l'installation d'un r�pertoire. Il est pr�f�rable de renommer le r�pertoire plut�t que de le supprimer, au cas o� vous auriez des probl�mes et que vous auriez besoin d'y revenir. Gardez en t�te que le r�pertoire peut prendre beaucoup d'espace disque. Pour renommer le r�pertoire, utilisez une commande comme celle-ci :
mv /usr/local/pgsql /usr/local/pgsql.old
Installez la nouvelle version de PostgreSQL™ comme indiqu�e dans la prochaine section Section�1.5, ��Proc�dure d'installation��.
Cr�ez un nouveau cluster de bases de donn�es. Rappelez-vous que vous devez ex�cuter ces commandes en utilisant le compte superutilisateur initial (que vous avez d�j� si vous mettez � jour).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Restaurez votre pr�c�dent pg_hba.conf et toutes les modifications de postgresql.conf.
Lancez le serveur de bases de donn�es, de nouveau � partir du compte superutilisateur :
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Enfin, restaurez vos donn�es � partir de votre sauvegarde avec :
/usr/local/pgsql/bin/psql -d postgres -f outputfile
en utilisant le nouveau psql.
Des informations suppl�mentaires apparaissent dans la documentation ??? incluant les instructions sur la fa�on dont l'installation pr�c�dente peut continuer � s'ex�cuter alors que le nouvelle est install�e.
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.
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™. 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 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.
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).
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 ��zic�� 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.
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 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 xml2-config utilis� pour localiser l'installation de libxml.
programme Yacc (bison -y si utilisation de Bison)
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 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 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.
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 (formellement 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 une syst�me d'exploitation donn�es fonctionneront. Cherchez dans le r�pertoire doc/ de la distribution des sources pour v�rifier s'il existe une FAQ sp�cifique � 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 connu 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-ports@postgresql.org> est l'endroit appropri� pour en discuter.