meson setup build --prefix=/usr/local/pgsql cd build ninja su ninja install adduser postgres mkdir -p /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/pg_ctl -D /usr/local/pgsql/data -l logfile start /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test
La version longue correspond au reste de cette section.
Configuration
La première étape de la procédure d'installation est de configurer le
répertoire de compilation pour votre système et de choisir les options que
vous souhaitez. Pour créer et configurer le répertoire de compilation, vous
pouvez démarrer avec la commande meson setup.
meson setup build
Cette commande d'initialisation prend comme argument un builddir
et un srcdir. Si aucun srcdir n'est fourni, Meson
va déduire le srcdir en se basant sur le répertoire courant et la
location de meson.build. Le builddir est obligatoire.
Exécuter meson setup charge le fichier de configuration
généré et initialise le répertoire de compilation. De plus, vous pouvez
aussi passer de nombreuses options de compilation à Meson. Certaines les
plus communément utilisées sont mentionnées dans les sections suivantes. Par
exemple :
# configure avec un préfixe d'installation différent : meson setup build --prefix=/home/user/pg-install # configure pour une compilation de débug : meson setup build --buildtype=debug # configure pour une compilation avec support OpenSSL : meson setup build -Dssl=openssl
Initialiser le répertoire de compilation est une étape qui s'effectue une
fois seulement. Pour reconfigurer une nouvelle compilation, vous pouvez
simplement utiliser la commande meson configure.
meson configure -Dcassert=true
Les options en ligne de commande de meson configure les
plus communément utilisées sont expliquées dans Section 17.4.3.
Compilation
Par défaut, Meson utilise l'outil de compilation
Ninja. Pour compiler
PostgreSQL depuis les sources en utilisant Meson,
vous devez simplement utiliser la commande ninja dans
le répertoire de compilation.
ninja
Ninja va automatiquement détecter le nombre de CPU dans votre ordinateur et
paralléliser lui-même en conséquence. Vous pouvez surcharger le nombre de
processus parallèles utilisés avec l'argument de ligne de commande
-j.
Prenez note qu'après l'étape initiale de configuration, ninja
est la seule commande que vous aurez besoin de saisir pour compiler.
Quelque soit la façon dont vous modifiez l'arborescence source (à moins de la
déplacer vers un emplacement complètement nouveau), Meson va détecter les
changements et se régénérer lui-même en conséquence. Ceci est particulièrement pratique
si vous avez de multiples répertoires de compilation. Souvent, l'un d'eux est
utilisé pour le développement (la compilation en mode « debug ») et les autres
seulement de temps en temps (telle que la compilation en mode « analyse statique »).
N'importe quelle configuration peut être compilée juste en se déplaçant via cd dans
le répertoire correspondant puis en exécutant Ninja.
Si vous souhaitez compiler avec un autre outil que ninja, vous pouvez
utiliser configure avec l'option --backend pour
sélectionner celui que vous voulez utiliser et compiler en utilisant
meson compile. Pour en savoir plus sur ces outils et les
autres arguments que vous pouvez fournir à ninja, vous pouvez vous référer à
la
documentation de Meson.
Tests de régression
Si vous voulez tester la nouvelle compilation du serveur avant de l'installer, vous pouvez exécuter des tests de régression à ce point. Les tests de régression sont une suite de test vérifiant que PostgreSQL s'exécute sur votre machine de la façon dont les développeurs l'attendent. Saisissez :
meson test
(Cela ne fonctionnera pas en tant que root ; exécutez-le avec un utilisateur non privilégié.) Voir Chapitre 31 pour des informations détaillées sur l'interprétation des résultats des tests. Vous pouvez répéter ce test plus tard en exécutant la même commande.
Pour exécuter les tests pg_regress et pg_isolation_regress sur une instance
postgres démarrée, préciser --setup running comme
argument à meson test.
Installer les fichiers
Si vous mettez à jour un système existant, soyez sûr de lire Section 18.6, qui indique les instructions pour mettre à jour une instance.
Une fois que PostgreSQL est compilé, vous pouvez l'installer simplement en
exécutant la commande ninja install.
ninja install
Ceci installera les fichiers dans les répertoires qui ont été spécifiés dans Étape 1. Assurez-vous que vous disposez des droits appropriés pour écrire dans ces zones. Vous pourriez avoir besoin de l'exécuter sous root. Alternativement, vous pouvez créer les répertoires cibles en avance et vous assurer de l'octroi des droits appropriées. L'installation standard fournit les fichiers entête nécessaire pour le développement d'application client aussi bien que le développement de programme côté serveur, comme des fonctions personnalisées ou des types de données écrits en C.
ninja install devrait fonctionner dans la plupart des
cas, mais si vous préférez plus d'options (telles que
--quiet pour supprimer les sorties supplémentaires), vous
pouvez aussi utiliser à la place meson install. Vous
pouvez en apprendre plus sur meson install et
ces options dans la documentation Meson.
Désinstallation.
Pour annuler l'installation, vous pouvez utiliser la commande
ninja uninstall.
Nettoyage.
Après l'installation, vous pouvez libérer l'espace disque en supprimant
les fichiers compilés depuis le répertoire source avec la commande
ninja clean.
meson setup #
Les options de la ligne de commande meson setup sont
explicitées ci-dessous. La liste n'est pas exhaustive (utiliser
meson configure --help pour obtenir l'exhaustivité). Les
options non couvertes ici sont destinées à des cas d'usage avancés, et sont
documentées dans la documentation de
Meson. Ces arguments peuvent être utilisés aussi bien avec
meson setup.
Ces options contrôlent où ninja install (ou
meson install) vont déposer les fichiers. L'option
--prefix (exemple Section 17.4.1)
est suffisante pour la plupart des cas. Si vous avez des besoins
particuliers, vous pouvez personnaliser les sous-répertoires
d'installation avec les autres options décrites dans cette section.
Attention, cependant, que tout changement relatif aux emplacements des
différents sous-répertoires peut rendre l'installation non déplaçable,
signifiant que vous ne pourrez plus la déplacer après l'installation.
(Les emplacements man et doc ne sont
pas affectés par cette restriction.) Pour des installations déplaçables,
vous pouvez vouloir utiliser l'option -Drpath=false
décrite plus loin.
--prefix=PREFIX #
Installe tous les fichier sous le répertoire
PREFIX au lieu de
/usr/local/pgsql (sur les systèmes basés sur Unix)
ou
lettre_lecteur_courant:/usr/local/pgsqlPREFIX.
--bindir=DIRECTORY #
Précise le répertoire pour des programmes exécutables. La valeur par
défaut est PREFIX/bin
--sysconfdir=DIRECTORY #
Précise le répertoire pour divers fichiers de configuration,
par défaut PREFIX/etc
--libdir=DIRECTORY #
Précise l'emplacement d'installation des bibliothèques et modules dynamiquement
chargeables. Le défaut est PREFIX/lib
--includedir=DIRECTORY #
Précise le répertoire pour installer les fichiers entêtes C et C++.
Le défaut est PREFIX/include
--datadir=DIRECTORY #
Précise le répertoire pour les fichiers de données en lecture seule utilisés
par les programmes installés. Le défaut est
PREFIX/share
--localedir=DIRECTORY #
Précise le répertoire pour installer les données des locales, en particulier
les fichiers du catalogue de traduction des messages. Le défaut est
DATADIR/locale
--mandir=DIRECTORY #
Les pages man qui viennent avec PostgreSQL seront
installées dans ce répertoire, dans leur sous-répertoires
man respectifs.
Le défaut est xDATADIR/man
Des précautions ont été prises pour rendre possible l'installation de
PostgreSQL dans des emplacements d'installation
partagés (tels que /usr/local/include) sans
interférer avec l'espace de noms du reste du système. D'abord la chaîne
« /postgresql » est automatiquement concaténée à
datadir, sysconfdir, et docdir,
à moins que le nom de répertoire pleinement étendu contienne déjà la chaîne
« postgres » ou « 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 cela sera dans
/opt/postgres/doc. Les fichiers entêtes C publiques des
interfaces clientes seront installés dans includedir et
sont propres à l'espace de noms. Les fichiers d'entête internes et les fichiers
d'entête serveur sont installés dans des répertoires privés sous includedir.
Voir la documentation pour chaque interface pour les informations d'accès aux
fichiers entêtes. Enfin, un sous-répertoire privé sera aussi créé, si cela est
approprié, sous libdir pour les modules dynamiquement
chargeables.
Les options décrites dans cette section permettent la compilation de
diverses fonctionnalités obsolètes de PostgreSQL.
La plupart requièrent des logiciels additionnels, comme décrit dans
Section 17.1, et seront automatiquement activées
si le logiciel requis est trouvé. Vous pouvez changer ce comportement
en mettant manuellement ces fonctionnalités à enabled
pour les demander ou disabled pour ne pas les intégrer
à la compilation.
Pour préciser les options spécifiques de PostgreSQL, le nom de l'option
doit être préfixée par -D.
-Dnls={ auto | enabled | disabled } #Active ou désactive le support de language natif (Native Language Support NLS), qui est la possibilité d'afficher les messages d'un programme dans une langue autre que l'anglais. Le défaut est auto et sera activé automatiquement si une implémentation de l'API Gettext est trouvée.
-Dplperl={ auto | enabled | disabled } #Compile le langage serveur PL/Perl. Le défaut est auto.
-Dplpython={ auto | enabled | disabled } #Compile le langage serveur PL/Python. Le défaut est auto.
-Dpltcl={ auto | enabled | disabled } #Compile le langage serveur PL/Tcl. Le défaut est auto.
-Dtcl_version=TCL_VERSION #Définit la version Tcl à utiliser lors de la compilation de PL/Tcl.
-Dicu={ auto | enabled | disabled } #Compile le support pour la bibliothèque ICU, activant l'utilisation des fonctionnalités des collations ICU (voir Section 23.2). Le défaut est auto et demande que le paquet ICU4C soit installé. La version minimale requise de ICU4C est actuellement 4.2.
-Dllvm={ auto | enabled | disabled } #Compile avec le support pour LLVM basé sur la compilation JIT (voir Chapitre 30). Cela nécessite d'installer la bibliothèque LLVM. La version minimale de LLVM est actuellement 3.9. Désactivé par défaut.
llvm-config
sera utilisée pour trouver les options de compilations requises.
llvm-config, et ensuite,
pour toutes les versions supportées, llvm-config-$version seront
recherchées dans votre PATH. Si cela ne donne pas le programme
souahité, utilisez LLVM_CONFIG pour définir un chemin vers le
llvm-config correct.
-Dlz4={ auto | enabled | disabled } #Compile avec le support de compression LZ4. Le défaut est auto.
-Dzstd={ auto | enabled | disabled } #Compile avec le support de compression Zstandard. Le défault est auto.
-Dssl={ auto | LIBRARY }
#
Compile avec le support pour les connexions (chiffrées)
SSL. La seule LIBRARY
supportée est openssl. Ceci nécessite que le paquet
OpenSSL soit installé. Compiler avec cette
option implique de vérifier les fichiers d'entête et bibliothèques
requises pour être sûr que votre installation
OpenSSL soit suffisante avant exécution. Le
défaut pour cette option est auto.
-Dgssapi={ auto | enabled | disabled } #
Compile avec le support de l'authentification GSSAPI. Il est nécessaire
que MIT Kerberos soit installé pour GSSAPI. Sur de nombreux systèmes, le
système GSSAPI (un sous-ensemble de l'installation MIT Kerberos) n'est
pas installé dans un emplacement recherché par défaut (i.e.
/usr/include, /usr/lib). Dans
ces cas, PostgreSQL va interroger pkg-config pour
détecter le compilateur requis et les options de lien. Le défaut est
auto. meson configure va vérifier pour les
fichiers d'entête et bibliothèques pour être sûr que votre installation
GSSAPI est suffisante avant exécution.
-Dldap={ auto | enabled | disabled } #
Compile avec le support pour l'authentification
LDAP et
la recherche de paramètre de connexion (voir Section 32.18 et Section 20.10 pour plus d'information). Sous Unix, ceci
nécessite d'installer le paquet OpenLDAP.
Sous Windows, la bibliothèque WinLDAP est
utilisée par défaut. Le défaut est auto. meson
configure va vérifier les fichiers d'entête et bibliothèques
requises pour s'assurer que votre installation
OpenLDAP est suffisante avant exécution.
-Dpam={ auto | enabled | disabled } #-Dbsd_auth={ auto | enabled | disabled } #Compile avec le support de l'authentification BSD. (Le système d'authentification BSD n'est actuellement disponible que sur OpenBSD.) Le défaut est auto.
-Dsystemd={ auto | enabled | disabled } #Compile avec le support de service de notifications systemd. Ceci améliore l'intégration si le serveur est démarré sous systemd mais n'a aucun impact autrement ; voir Section 18.3 pour plus d'information. Le défaut est auto. libsystemd et les fichiers d'entête associés doivent être installés pour utiliser cette option.
-Dbonjour={ auto | enabled | disabled } #Compile avec le support pour le service de découverte automatique Bonjour. Le défaut est auto et nécessite le support de Bonjour sur votre système d'exploitation. Recommandé sur macOS.
-Duuid=LIBRARY #
Compile le module uuid-ossp (qui fournit les fonctions
de génération des UUID), utilisant la bibliothèque UUID spécifiée.
LIBRARY peut valoir :
none pour ne pas compiler le module. C'est le défaut.
bsd pour utiliser les fonctions UUID trouvées dans
FreeBSD, et dans certains systèmes dérivés de BSD.
e2fs pour utiliser la bibliothèque UUID créée par le
projet e2fsprogs ; cette bibliothèque est
présente sur la plupart des systèmes Linux comme sur macOS, et peut
aussi bien être obtenue pour d'autres plateformes.
ossp pour utiliser la bibliothèque OSSP UUID
-Dlibxml={ auto | enabled | disabled } #Compile avec libxml2, activant le support de SQL/XML. Le défaut est auto. La version 2.6.23 de libxml2 ou supérieure est nécessaire pour cette fonctionnalité.
Pour utiliser une installation libxml2 dans un emplacement inhabituel,
vous pouvez définir les variables d'environnement
pkg-config associées (voir sa documentation).
-Dlibxslt={ auto | enabled | disabled } #
Compile avec lbxslt, activant le xml2module de
transformation XSL du XML. L'option -Dlibxml doit
aussi être définiée. Le défaut est auto.
-Dselinux={ auto | enabled | disabled } #Build with SElinux support, enabling the sepgsql extension. Defaults to auto.
-Dreadline={ auto | enabled | disabled } #Permet l'utilisation de la bibliothèque Readline (et aussi libedit). Le défaut de l'option est auto et active l'édition et historique de la ligne de commande avec psql et est fortement recommandée.
-Dlibedit_preferred={ true | false } #Mettre ces options à true favorise l'utilisation de la bibliothèque en license BSD libedit plutôt que la bibliothèque en license GPL Readline. Cette option est pertinente seulement si vous avez les deux bibliothèque installées ; le défaut est false, ce qui fait utiliser Readline.
-Dzlib={ auto | enabled | disabled } #Active l'utilisation de la bibliothèque Zlib. Le défaut est auto et active le support des archives compressées dans pg_dump, pg_restore et pg_basebackup, ce qui est recommandée.
-Dspinlocks={ true | false } #Cette option vaut true par défaut ; l'affecter à false va permettre de compiler avec succès même si PostgreSQL n'a pas de support spinlock CPU pour la plateforme. L'absence de support spinlock va donner de mauvaises performances ; par conséquent, cette option ne devrait être changée que si la compilation échoue et vous informe que la plateforme n'a pas de support spinlock. S'il faut affecter cette option pour compiler PostgreSQL sur votre plateforme, merci d'indiquer le problème aux développeurs PostgreSQL.
-Datomics={ true | false } #Cette option est mise à true par défaut ; l'affecter à false va désactiver l'utilisation d'opérations atomiques CPU. Cette option ne fait rien sur les plateformes qui n'ont pas ce genre d'opérations. Sur les plateformes qui les ont, désactiver les opérations atomiques donnera de mauvaises performances. Modifier cette option n'est seulement utile que pour du debug ou pour faire des comparaisons de performances.
--auto_features={ auto | enabled | disabled } #Affecter cette option permet d'écraser les valeurs de toutes les fonctionnalités « auto » (les fonctionnalités qui sont activées automatiquement si le logiciel requis est trouvé). Ceci peut être utile quand vous souhaitez désactiver ou activer les fonctionnalités « optionnelles » d'un coup sans le faire pour chacune d'elle manuellement. La valeur par défaut pour ce paramètre est auto.
--backend=BACKEND #
L'outil que Meson utilise par défaut est ninja et il devrait suffire
pour la plupart des cas. Cependant, si vous souhaitez complètement vous
intégrer avec Visual Studio, vous pouvez mettre
BACKEND à vs.
-Dc_args=OPTIONS #Cette option est utilisée pour passer des options supplémentaires pour le compilateur C.
-Dc_link_args=OPTIONS #Cette option est utilisée pour passer des options complémentaires à l'éditeur de liens C.
-Dextra_include_dirs=DIRECTORIES #
DIRECTORIES est une liste de répertoires
séparés par des virgules qui seront ajoutés dans la liste de recherche
du compilateur pour les fichiers d'entête. Si vous avez des paquets
optionnels (tels que GNU Readline) installés
dans des emplacements non standard, vous devez utiliser cette option et
probablement aussi l'option correspondante
-Dextra_lib_dirs.
Exemple : -Dextra_include_dirs=/opt/gnu/include,/usr/sup/include.
-Dextra_lib_dirs=DIRECTORIES #
DIRECTORIES est une liste de répertoires
séparés par des virgules pour rechercher les bibliothèques. Vous devrez
probablement utiliser cette option (et l'option correspondante
-Dextra_include_dirs) si vous avez des paquets
installés dans des emplacements non standard.
Exemple : -Dextra_lib_dirs=/opt/gnu/lib,/usr/sup/lib.
-Dsystem_tzdata=DIRECTORY
#
PostgreSQL inclut sa propre base de données
de fuseaux horaires, qui est requise pour les opérations sur les dates
et heures. Cette base de données de fuseaux horaires est en fait
compatible avec la base de données de fuseaux horaires IANA fournie par
de nombreux systèmes d'exploitation tel que FreeBSD, Linux et Solaris.
Il serait ainsi redondant de l'installer à nouveau. Quand cette option
est utilisée, la base de données de fuseaux horaires fournie par le
système dans DIRECTORY est utilisée au lieu
de celle incluse dans la distribution source PostgreSQL.
DIRECTORY doit être spécifiée sous forme de
chemin absolu. /usr/share/zoneinfo est un
répertoire approprié sur certains systèmes d'exploitation. Notez que la
routine d'installation ne détectera pas les données de fuseaux horaires
non compatibles ou erronées. Si vous utilisez cette option, soyez avisé
d'exécuter des tests de régression pour vérifier que les données de
fuseaux horaires que vous indiquez fonctionnent correctement avec
PostgreSQL.
Cette option vise principalement les distributeurs de paquets binaires qui connaissent bien le système d'exploitation cible. Le principal avantage d'utiliser cette option est que les paquets PostgreSQL n'ont pas besoin d'être mis à jour dès qu'une des nombreuses règles locales d'heure d'été change. Un autre avantage est que PostgreSQL peut être compilé de manière croisée plus simplement si les fichiers de fuseaux horaires n'ont pas à être compilés pour l'installation.
-Dextra_version=STRING #
Ajoute STRING au numéro de version
PostgreSQL. Vous pouvez avec cela, par exemple, marquer les binaires
compilés d'un instantané Git inédit ou
contenant des patchs personnalisés avec une chaîne supplémentaire de
version, telle qu'un identifiant git describe ou un
numéro de livraison de paquets de distribution.
-Drpath={ true | false } #
Cette option vaut true par défaut. Si mise à false, les exécutables
PostgreSQL ne sont pas marqués pour indiquer
qu'ils doivent chercher les bibliothèques partagées dans le répertoire
de bibliothèques de l'installation (voir --libdir).
Sur la plupart des plateformes, ce marquage utilise un chemin absolu
vers les répertoires de bibliothèques, de sorte que cela ne sera
d'aucune utilité si vous déplacez l'installation plus tard. Dans ce cas,
vous devrez alors fournir une autre façon aux exécutables de trouver les
bibliothèques partagées. Habituellement, cela demande de configurer
l'éditeur de liens dynamique du système d'exploitation pour pointer le
répertoire de bibliothèques ; voir Section 17.5.1 pour plus de détails.
-DBINARY_NAME=PATH #
Si un programme requis pour compiler PostgreSQL (avec ou sans drapeaux
optionnels) est stocké sur un chemin non standard, vous pouvez le
spécifier manuellement à meson configure. La liste
complète des programmes pour lesquels ceci est supporté peut être trouvé
en exécutant meson configure.
Exemple :
meson configure -DBISON=PATH_TO_BISON
Voir Section J.2 pour les outils nécessaires pour compiler la documentation.
-Ddocs={ auto | enabled | disabled } #Active la compilation de la documentation en format HTML et man. Son défaut est auto.
-Ddocs_pdf={ auto | enabled | disabled } #Active la compilation de la documentation en format PDF. Son défaut est auto.
-Ddocs_html_style={ simple | website } #
Contrôle quelle feuille de style CSS est utilisée.
Le défaut est simple. Si mis à website,
la documentation HTML va référencer la feuille de style pour postgresql.org.
-Dpgport=NUMBER #
Affecte NUMBER comme numéro de port par
défaut pour le serveur et les clients. Le défaut est 5432. Le port peut
toujours être changé après, mais si vous le spécifiez ici alors le
serveur et les clients auront la même valeur compilée par défaut, ce qui
peut être très pratique. Habituellement la seule bonne raison de choisir
une valeur différente du défaut est si vous prévoyez d'exécuter
plusieurs serveurs PostgreSQL sur la même
machine.
-Dkrb_srvnam=NAME #
Le nom par défaut du compte de service Kerberos utilisé par GSSAPI.
postgres est la valeur par défaut. Il n'y a,
habituellement, pas de raison de changer ceci sauf si vous compilez sur
un environnement Windows, et dans ce cas, il doit être en casse haute
POSTGRES.
-Dsegsize=SEGSIZE #Affecte la taille du segment en giga-octets. Les tables volumineuses sont divisées en plusieurs fichiers sur le système d'exploitation, chacune ayant la taille d'un segment. Ceci permet d'éviter des problèmes dûs aux limites de taille de fichier qui existent sur de nombreuses plateformes. La taille par défaut du segment, 1 giga-octet, est sûre sur toutes les plateformes supportées. Si votre système d'exploitation a le support « largefile » (ce qui est le cas pour la plupart, de nos jours), vous pouvez utiliser une taille de segment plus large. Ceci peut être utile pour réduire le nombre de descripteurs de fichiers utilisés lorsque vous travaillez sur des tables volumineuses. Mais soyez prudent de ne pas choisir une valeur plus large que ne peut supporter votre plateforme et le système de fichiers que vous prévoyez d'utiliser. D'autres outils que vous pourriez utiliser, tel que tar, pourrait aussi limiter la taille utilisable d'un fichier. Il est recommandé, mais pas absolument nécessaire, que cette value soit une puissance de 2.
-Dblocksize=BLOCKSIZE #Affecte la taille de bloc, en kilo-octets. Ceci est l'unité de stockage et d'I/O à l'intérieur des tables. Le défaut, 8 kilo-octets, est approprié pour la majorité des situations ; mais d'autres valeurs peuvent être utiles dans des cas spéciaux. Cette valeur doit être une puissance de 2 entre 1 et 32 (kilo-octets).
-Dwal_blocksize=BLOCKSIZE #Affecte la taille de bloc d'un journal de transactions, en kilo-octets. C'est l'unité de stockage et d'I/O à l'intérieur des journaux WAL. Le défaut, 8 kilo-octets, est approprié pour la majorité des situations ; mais d'autres valeurs peuvent être utiles dans des cas spéciaux. Cette valeur doit être une puissance de 2 entre 1 et 64 (kilo-octets).
La plupart des options dans cette section sont seulement intéressantes pour
le développement ou le debug de PostgreSQL.
Elles ne sont pas recommandées pour les compilations de production, sauf
pour --debug, qui peut être utile pour activer les
rapports de bug détaillés si vous avez l'infortune de rencontrer un bug.
Sur les plateformes supportant DTrace, l'option -Ddtrace
pourrait aussi être raisonnablement utilisée en production.
Lorsque vous compilez une installation qui sera utilisé pour développer du
code serveur, il est recommandé d'utiliser au moins les options
--buildtype=debug et -Dcassert.
--buildtype=BUILDTYPE #
Cette option peut être utilisée pour indiquer le type de compilation à
utiliser ; le défaut est debugoptimized. Si vous
préférez un contrôle plus fin sur les symboles de debug et les niveaux
d'optimisation que cette option peut fournir, vous pouvez vous référer
aux drapeaux --debug et
--optimization.
Les types de compilation suivants sont principalement utilisés :
plain, debug,
debugoptimized et release. Plus
d'information à leur sujet peut être trouvé dans la documentation
Meson.
--debug #Compile tous les programmes et bibliothèques avec les symboles de debug. Cela signifie que vous pouvez exécuter les programmes dans une debugger pour analyser les problèmes. Ceci augmente fortement la taille des exécutables installés, et sur les compilateurs non GCC, désactive habituellement aussi les optimisations compilateur, entrainant des ralentissements. Cependant, avoir les symboles disponibles peut s'avérer extrêmement utile pour gérer tous les problèmes qui peuvent survenir. Actuellement, cette option est recommandée sur des installations de production uniquement si vous utilisez GCC. Mais vous devrez toujours l'avoir si vous effectuez des travaux de développement ou exécutez une version bêta.
--optimization=LEVEL #
Indique le niveau d'optimisation. LEVEL peut être
affecté à n'importe quelle valeur de {0,g,1,2,3,s}.
--werror #Activer cette option indique au compilateur de traiter les avertissements comme des erreurs. Cela peut être utile pour du développement.
-Dcassert={ true | false } #Active les vérifications d'assertion sur le serveur, qui testent de nombreuses conditions qui « ne peuvent se produire ». Ceci est très appréciable dans le but de développer du code, mais les tests ralentissent notablement le serveur. De plus, avoir les tests activés ne va pas nécessairement améliorer la stabilité de votre serveur ! Les vérifications d'assertion ne sont pas catégorisées par sévérité, ainsi ce qui pourrait être un bug relativement inoffensif peut entrainer un redémarrage de serveur s'il déclenche un échec d'assertion. Cette option n'est pas recommandée pour une utilisation en production, mais vous pouvez l'activer lors de travaux de développement ou en testant une version bêta.
-Dtap_tests={ auto | enabled | disabled } #
Active les tests utilisant les outils Perl TAP. Le défaut est auto et
nécessite une installation de Perl et du module Perl
IPC::Run. Voir
Section 31.4 pour plus d'information.
-DPG_TEST_EXTRA=TEST_SUITES #Active les suites de tests qui nécessitent un logiciel particulier pour s'exécuter. Cette option accepte les arguments via une liste de valeurs séparées par des espaces. Voir Section 31.1.3 pour plus de détails.
-Db_coverage={ true | false } #Si vous utilisez GCC, tous les programmes et bibliothèques seront compilées avec une instrumentation de test de couverture de code. Exécutés, ils généreront des fichiers dans le répertoire de debug avec des mesures de couverture de code. Voir Section 31.5 pour plus d'information. Cette option n'est utilisable qu'avec GCC et pour effectuer des travaux de développement.
-Ddtrace={ auto | enabled | disabled } #Activée, cette option compile PostgreSQL avec le support pour l'outil de profilage dynamique DTrace. Voir Section 27.5 pour plus d'informations.
Pour pointer le programme dtrace, l'option
DTRACE peut être valuée. Ceci est souvent nécessaire
parce que dtrace est habituellement installé sous
/usr/sbin, qui pourrait ne pas être dans votre
PATH.
-Dinjection_points={ true | false } #Compiles PostgreSQL with support for injection points in the server. Injection points allow to run user-defined code from within the server in pre-defined code paths. This helps in testing and in the investigation of concurrency scenarios in a controlled fashion. This option is disabled by default. See Section 36.10.13 for more details. This option is intended to be used only by developers for testing.
-Dsegsize_blocks=SEGSIZE_BLOCKS #
Cette option est destinée aux développeurs pour tester le code en lien
aux segments. Indique la taille de segment d'une relation en blocs. Si
l'option -Dsegsize et celle ci sont affectées, cette
option l'emporte.
meson #
Des cibles individuelles de construction peuvent être construites en
utilisant ninja cible.
Quand aucune cible n'est indiquée, tout est construit sauf la documentation.
Les produits individuels de construction peuvent être construit en utilisant
le chemin/nom du fichier comme cible.
html #Construit la documentation dans un format multi-page HTML
man #Construit la documentation dans le format des pages man
docs #Construit la documentation dans le format multi-page HTML et page man
doc/src/sgml/postgres-A4.pdf #Construit la documentation au format PDF, avec des pages A4
doc/src/sgml/postgres-US.pdf #Construit la documentation au format PDF, avec des pages lettre US
doc/src/sgml/postgres.html #Construit la documentation au format HTML sur une seule page
alldocs #Construit la documentation dans tous les formats supportés
install #Installe postgres, sauf la documentation
install-docs #Installe la documentation au format multi-page HTML et page man
install-html #Installe la documentation au format multi-page HTML
install-man #Installe la documentation au format page man
install-quiet #Comme "install", mais les fichiers installés ne sont pas affichés
install-world #Installe postgres, incluant la documentation au format multi-page HTML et page man
uninstall #Supprime les fichiers installés