Documentation PostgreSQL 15.15 » Administration du serveur » Procédure d'installation depuis le code source » Notes spécifiques à des plateformes

Précédent | Niveau supérieur | Suivant
17.6. Plateformes supportées | Sommaire | Chapitre 18. Installation à partir du code source sur Windows

## 17.7. Notes spécifiques à des plateformes

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.2. 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.

### 17.7.1. AIX

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.

#### 17.7.1.1. Gestion de la mémoire

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`n`0000000`, 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:0x`n`0000000"` pour obtenir le même résultat.

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.

### 17.7.2. Cygwin

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 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 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 package binaire PostgreSQL sur Cygwin. Il est installé dans le répertoire `/usr/share/doc/Cygwin`.

### 17.7.3. macOS

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.

### 17.7.4. MinGW/Windows Natif

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.

#### 17.7.4.1. Récupérer des dumps suite aux plantages sous Windows

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.

### 17.7.5. Solaris

PostgreSQL est bien supporté sous Solaris. Plus le système d'exploitation est à jour, moins vous aurez de problèmes.

#### 17.7.5.1. Outils requis

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 packages 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.

#### 17.7.5.2. configure se plaint d'un programme de test en échec

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.

#### 17.7.5.3. Compiler pour des performances optimales

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.

#### 17.7.5.4. Utiliser DTrace pour tracer PostgreSQL

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.