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 17.1. Par ailleurs, consultez Chapitre 33 à 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.
Pour construire PostgreSQL à partir des sources sur macOS, vous aurez besoin d'installer les outils développeur en ligne de commande d'Apple, ce qui se fait en exécutant
xcode-select --install
(notez que cela affichera une fenêtre graphique pour confirmation). Vous pouvez aussi installer Xcode.
Vous pouvez utiliser GCC ou le compilateur natif d'IBM xlc
pour construire PostgreSQL sur
AIX.
Les versions d'AIX avant la 7.1 ne sont plus testés et supportées par la communauté PostgreSQL.
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, et malgré tout avoir des erreurs de mémoire insuffisante ou des erreurs d'espace d'adressage quand vous lancez des applications. Un exemple est le chargement d'extensions qui échoue avec des erreurs inhabituelles. Par exemple, en exécutant en tant que propriétaire de l'installation PostgreSQL :
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
En l'exécutant en tant que non-propriétaire, mais dans le groupe propriétaire de l'installation PostgreSQL :
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
On a un autre exemple avec les erreurs out of memory dans les traces du serveur PostgreSQL, avec toutes les allocations de mémoire vers 256 Mo ou plus qui échouent.
La cause générale de ces problèmes est le nombre de bits et le modèle mémoire utilisés 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 modèle parmi quelques-uns. 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 plperl
ci-dessus, vérifiez
votre umask et les droits des binaires de l'installation PostgreSQL.
Les binaires de l'exemple étaient en 32 bits et installés en mode 750 au lieu
de 755. En raison de ces 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 monde, 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 » 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 pas exécuter, des binaires 64 bits.
Si un binaire 32 bits est souhaité, positionnez LDR_CNTRL
à MAXDATA=0x
,
où 1<=n <= 8 avant de démarrer le serveur PostgreSQL, et essayez
différentes valeurs et paramètres de n
0000000postgresql.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:0x
pour obtenir le même résultat.
n
0000000"
Pour une compilation en 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. Lorsque OBJECT_MODE
est
positionné, il indique aux outils de compilation d'AIX comme
ar
, as
et
ld
quel type 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 sera accédée. Le comportement le plus proche de ceci que nous ayons constaté est l'échec d'un 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 l'arrêt suite à un « out-of-memory » sont configurables, soit pour le système, soit pour un processus, si cela devient un problème.
PostgreSQL peut être compilé avec Cygwin, un environnement similaire à Linux pour Windows, mais cette méthode est inférieure à la version native Windows (voir Chapitre 18) et faire tourner un serveur sur Cygwin n'est plus recommandé.
Quand vous compilez à partir des sources, suivant la procédure
d'installation de style Unix (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 évitera des problèmes à la compilation.
La commande adduser
n'est pas supportée ; utilisez
les outils appropriés de gestion d'utilisateurs sous Windows.
Sinon, sautez cette étape.
La commande su
n'est pas supportée ; utilisez ssh
pour simuler la commande su
sous Windows. 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 compilation échoue sur certains systèmes 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 compilation,
puis, une fois PostgreSQL installé, 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 connexions 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 paquets binaire PostgreSQL sur Cygwin.
Il est installé dans le répertoire /usr/share/doc/Cygwin
.
Sur les versions récentes de macOS, il est
nécessaire d'embarquer le chemin « sysroot » dans les options
d'inclusion utilisées pour trouver les fichiers d'en-tête système. Ceci a
pour résultat la génération d'un script
configure variant suivant la version du SDK
utilisée durant configure. Ceci ne devrait pas
poser de problèmes dans les scénarios simples, mais si vous essayez de
faire quelque chose comme compiler une extension sur une machine
différente de celle sur laquelle le code serveur a été compilé, vous
pouvez avoir besoin de forcer l'utilisation d'un chemin sysroot
différent. Pour cela, configurez PG_SYSROOT
ainsi
make PG_SYSROOT=/desired/path
all
Pour trouver le chemin approprié sur votre machine, lancez
xcrun --show-sdk-path
Notez que compiler une extension en utilisant une version sysroot différente de celle utilisée pour compiler le serveur n'est pas vraiment recommandée ; dans le pire des cas, cela peut entraîner des incohérences d'ABI difficiles à débugger.
Vous pouvez aussi sélectionner un chemin sysroot différent de celui par
défaut lors du configure
en indiquant PG_SYSROOT
à
configure :
./configure ... PG_SYSROOT=/desired/path
Ceci sera principalement utile pour faire de la cross-compilation pour d'autres versions de macOS. Il n'y a pas de garantie que les exécutables qui vont en résulter fonctionneront sur l'hôte actuel.
Pour supprimer les options -isysroot
, utilisez
./configure ... PG_SYSROOT=none
(tout nom de chemin non existant fonctionnera). Ceci pourrait être utile si vous souhaitez compiler avec un compilateur autre que celui d'Apple, mais attention au fait que ce cas n'est ni testé ni supporté par les développeurs PostgreSQL.
La fonctionnalité « System Integrity Protection » (SIP) de
macOS casse make check
,
car elle empêche de transmettre la configuration nécessaire de
DYLD_LIBRARY_PATH
vers les exécutables en cours de
tests. Vous pouvez contourner cela en exécutant make
install
avant make check
. Ceci étant dit, la
plupart des développeurs Postgres désactivent simplement SIP.
PostgreSQL pour Windows peut être compilé en utilisant MinGW, un environnement de compilation similaire à celui disponible sous 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 Chapitre 18.
Le port natif Windows requiert une version 32 ou 64 bits de Windows 2000 ou ultérieurs.
Les systèmes d'exploitation antérieurs 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 à partir 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 compiler les binaires 64 bits avec MinGW, installez l'ensemble d'outils 64 bits à
partir de https://mingw-w64.org/, 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 avez 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éez 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 processus planté et du moment du plantage.
PostgreSQL est bien supporté sous Solaris. Plus le système d'exploitation est à jour, moins vous aurez de problèmes.
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. 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 https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. De nombreux outils GNU sont intégrés dans Solaris 10, ou sont présents sur le Solaris companion CD. Si vous avez besoin des paquets pour des versions plus anciennes de Solaris, vous pouvez trouver ces outils sur http://www.sunfreeware.com. Si vous préférez les sources, allez sur https://www.gnu.org/order/ftp.html.
Si configure
se plaint d'un programme de test en échec,
il s'agit probablement 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 lui indiquer le bon endroit, positionnez
la variable d'environnement LDFLAGS
sur la ligne de commande
de configure
, par exemple,
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
Voir la man page de ld pour plus d'informations.
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 modifiant le comportement
des opérations à virgule flottante ni le traitement de
errno
(par exemple, -fast
).
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, donc le code 32 bits est significativement plus lent sur cette famille de processeurs.
Oui, l'utilisation de DTrace est possible. Voir Section 28.5 pour davantage d'informations.
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 make: *** [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 pour utiliser DTrace.