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 31 à 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 peut être compilé avec Cygwin, un environnement similaire à Linux pour Windows, mais cette méthode est inférieure à la version native Windows et exécuter 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. La variante de compilation MinGW utilise le système de compilation normal décrit dans ce chapitre.
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 27.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.
Il est recommandé que les utilisateurs téléchargent la version binaire pour Windows, disponible sous la forme d'un installeur graphique à partir du site PostgreSQL sur https://www.postgresql.org/download/. Construire à partir des sources est principalement utilisé par les personnes développant le moteur PostgreSQL ou des extensions.
PostgreSQL pour Windows avec Visual Studio peut être construit avec meson, comme décrit dans Section 17.4. Le port natif nécessite une version 32 ou 64 bits de Windows 10 (ou une version ultérieure).
Les constructions natives de psql n'acceptent pas l'édition de la ligne de commande. La construction Cygwin accepte l'édition en ligne de commande, donc elle doit être utilisée quand psql est nécessaire pour une utilisation interactive sur Windows.
PostgreSQL peut être construit avec la suite de compilateur Visual C++ de Microsoft. Ces compilateurs peuvent venir de These compilers can be either from Visual Studio, Visual Studio Express ou certaines versions du Microsoft Windows SDK. Si vous n'avez pas déjà un environnement Visual Studio de configuré, le plus simple revient à utiliser les compilateurs de Visual Studio 2022 ou ceux du Windows SDK 10, qui sont tous les deux disponibles sous la forme de téléchargement gratuit sur le site de Microsoft.
Des constructions 32 bits et 64 bits sont possibles avec la suite Microsoft Compiler. Les constructions 32 bits de PostgreSQL sont possibles de Visual Studio 2015 à Visual Studio 2022, ainsi qu'avec la version autonome du Windows SDK, versions 10 et supérieures. Les constructions 64 bits sont possibles avec Microsoft Windows SDK version 10 et ultérieur ou Visual Studio 2015 et ultérieur.
Si votre environnement de construction ne vient pas avec une version supportée du Microsoft Windows SDK, il est recommendé de metre à jour vers la dernière version (actuellement la 10), disponible en téléchargement à partir de https://www.microsoft.com/download.
Vous devez toujours inclure la partie Windows Headers and Libraries du SDK. Si vous installez un Windows SDK incluant Visual C++ Compilers, vous n'avez pas besoin de Visual Studio pour le construire. Notez qu'à partir de la version 8.0a, le Windows SDK n'apporte plus un environnement complet en ligne de commande.
Les produits supplémentaires suivants sont requis pour construire PostgreSQL sur Windows.
ActiveState Perl est requis pour exécuter les scripts de génération de la construction. MinGW ou Cygwin Perl ne fonctionneront pas. Il doit être en plus présent dans le PATH. Les binaires sont téléchargeables à partir de https://www.activestate.com (Note : la version 5.14 ou ultérieure est requise, la Standard Distribution libre est suffisante).
Bison et Flex sont requis. Seules les versions 2.3 et ultérieures de Bison fonctionneront. Flex doit être en version 2.5.35 ou ultérieur.
Bison et Flex sont inclus dans la suite d'outils msys, disponible à partir de http://www.mingw.org/wiki/MSYS dans la suite de compilation MinGW.
Vous aurez besoin d'ajouter le répertoire contenant
flex.exe et bison.exe à la
variable d'environnement. Dans le cas de MinGW, ce répertoire correspond
au sous-répertoire \msys\1.0\bin de votre répertoire
d'installation MinGW.
La distribution Bison de GnuWin32 semble avoir un bug qui ne permet
pas à Bison de fonctionner correctement quand il est installé dans
un répertoire dont le nom contient des espaces, par exemple avec
l'emplacement par défaut sur les installations en anglais
C:\Program Files\GnuWin32. Pensez à l'installer
dans C:\GnuWin32 ou utilisez le chemin court
NTFS dans la configuration de votre variable d'environnement PATH
(c'est-à-dire C:\PROGRA~1\GnuWin32).
Les produits supplémentaires suivants ne sont pas requis pour commencer mais ils sont requis pour construire le paquet complet.
Requis pour construire PL/Tcl (note : la version 8.4 est requise, la Standard Distribution libre est suffisante).
Diff est requis pour exécuter les tests de régression et peut être téléchargé à partir de http://gnuwin32.sourceforge.net.
Gettext est requis pour construire avec le support de NLS, et peut être téléchargé à partir de http://gnuwin32.sourceforge.net. Notez que les binaires, dépendances et fichiers développeur sont tous nécessaires.
Requis pour le support de l'authentification GSSAPI. MIT Kerberos peut être téléchargé à partir de https://web.mit.edu/Kerberos/dist/index.html.
Requis pour le support de XML. Les binaires peuvent être téléchargées à partir de https://zlatkovic.com/pub/libxml et les sources à partir de http://xmlsoft.org. Notez que libxml2 requiert iconv, qui est disponible à partir du même emplacement de téléchargement.
Requis pour accepter la compression LZ4. Les binaires et les sources peuvent être téléchargés à partir de https://github.com/lz4/lz4/releases.
Requis pour accepter la compression Zstandard. Les binaires et les sources peuvent être téléchargés à partir de https://github.com/facebook/zstd/releases.
Requis pour le support de SSL. Les binaires et peuvent être téléchargés à partir de https://slproweb.com/products/Win32OpenSSL.html alors que les sources sont disponibles sur https://www.openssl.org.
Requis pour le support de UUID-OSSP (uniquement pour le module contrib). Les sources peuvent être téléchargés à partir de http://www.ossp.org/pkg/lib/uuid/.
Requis pour construire PL/Python. Les binaires peuvent être téléchargés à partir de https://www.python.org.
Requis pour le support de la compression dans pg_dump et pg_restore. Les binaires peuvent être téléchargés à partir de https://www.zlib.net.
PostgreSQL pourra seulement être construit pour l'architecture x64 sur un Windows 64 bits.
Mixer les versions 32 et 64 bits dans le même arbre de construction n'est pas supporté. Le système de construction détectera automatiquement s'il fonctionne sur un environnement 32 ou 64 bits, et construira PostgreSQL suivant cela. Pour cette raison, il est important de lancer la bonne invite de commande avant de lancer la construction.
Pour utiliser une bibliothèque tierce côté serveur, comme Python ou OpenSSL, cette bibliothèque doit aussi être en 64 bits. Il n'est pas possible de charger une bibliothèque 32 bits sur un serveur 64 bits. Certaines bibliothèquestierces pourraient être uniquement disponibles en version 32 bits, auquel cas elles ne pourront pas être utilisées avec un PostgreSQL 64 bits.
Si PostgreSQL sur Windows s'arrête brutalement, il peut générer des
minidumps qui peuvent être utilisés pour
trouver la cause du crash, tout comme les core
dumps sous Unix. Ces dumps
peuvent être lus en utilisant Windows Debugger
Tools ou Visual Studio. Pour
activer la génération de dumps sous
Windows, créez un sous-répertoire nommé crashdumps
dans le répertoire de données principal de l'instance. Les
dumps seront alors écrits dans ce
répertoire avec un nom unique basé sur l'identifiant du processus qui
s'est arrếté brutalement et l'heure de l'arrêt.