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 15.2, « Prérequis ». Par ailleurs, consultez le fichier src/test/regress/README et la documentation Chapitre 30, Tests de régression à 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.
Les niveaux minimums recommandés de correctifs pour les versions supportées de AIX sont :
Maintenance Level 11 + post ML11 bundle
Maintenance Level 9 + post ML9 bundle
Technology Level 10 Service Pack 3
Technology Level 7
Base Level
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.
Utilisez les options de configure en plus de vos propres options si vous avez installé Readline ou libz dans /usr/local : --with-includes=/usr/local/include --with-libraries=/usr/local/lib.
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 davantage 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 AIX approprié indiqué ci-dessus 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 sur AIX 5.3.
Chacune des actions suivantes « corrige » 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.
![[Avertissement]](images/warning.png)
Ceci est en réalité un contournement des problèmes relatifs à l'immaturité du support IPv6, qui a amélioré la visibilité pour les versions 5.3 d'AIX. Cela a fonctionné avec les versions 5.3 d'AIX mais n'en fait pas pour autant une solution élégante à ce problème. Certaines personnes ont indiqué que ce contournement est non seulement inutile, mais pose aussi des problèmes sur AIX 6.1, où le support IPv6 est beaucoup plus mature.
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 plperl template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plperl.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 plperl template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plperl.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 Chapitre 16, Installation à partir du code source sur Windows™) et faire tourner un serveur sur Cygwin n'est plus recommandé.
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.
Il se peut que la construction échoue sur certains système quand une locale autre que C est utilisée. Pour résoudre ce problème, positionnez la locale à C avec la commande export LANG=C.utf8 avant de lancer la construction, et ensuite, une fois que vous avez installé PostgreSQL, repositionnez-là à son ancienne valeur.
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 :
Plateformes supportées
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 documentationChapitre 16, Installation à partir du code source sur Windows™. 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.
Pour construire les binaires 64 bits avec MinGW, installez l'ensemble d'outils 64 bits à partir de http://mingw-w64.sourceforge.net/, ajoutez le répertoire des binaires de MinGW dans la variable d'environnement PATH, et lancez la commande configure avec l'option --host=x86_64-w64-mingw32.
Après que vous ayez tout installé, il vous est conseillé de lancer psql dans CMD.EXE, car la console MSYS a des problèmes de tampons.
Si PostgreSQL sous Windows plante, il peut générer des minidumps™ qui peuvent être utilisés pour dépister la cause du plantage ; ils sont semblables aux core dumps d'Unix. Vous pouvez lire ces dumps avec Windows Debugger Tools™ ou avec Visual Studio™. Pour permettre la génération des dumps sous Windows, crééz un sous-répertoire nommé crashdumps dans le répertoire des données du cluster. Ainsi les dumps seront écrits dans ce répertoire avec un nom unique généré à partir de l'identifiant du process planté et le moment du plantage.
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 http://www.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/sgare/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/share/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.
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 Section 27.4, « Traces dynamiques » 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.