Le nom de la base de données à sauvegarder. En l'absence de précision, la variable d'environnement PGDATABASE est utilisée. Si cette variable n'est pas positionnée, le nom de l'utilisateur de la connexion est utilisé.

Seules les données sont sauvegardées, pas le schéma (définition des données). Les données des tables, les Large Objects, et les valeurs des séquences sont sauvegardées.

Cette option est similaire à --section=data mais, pour des raisons historiques, elle n'est pas identique.

Inclut les objets larges dans la sauvegarde. C'est le comportement par défaut, sauf si une des options suivantes est ajoutée : --schema, --table ou --schema-only. L'option -b n'est de ce fait utile que pour ajouter des Large Objects aux sauvegardes pour lesquelles un schéma particulier ou une table particulière a été demandée. Notez que les Large Objects sont considérés comme des données et, de ce fait, seront inclus si --data-only est utilisé, mais pas quand --schema-only l'est.

Les commandes de nettoyage (suppression) des objets de la base sont écrites avant les commandes de création. (À moins que --if-exists ne soit également spécifié, la restauration peut générer des messages d'erreur sans gravité si des objets ne sont pas présents dans la base de données de destination.)

Cette option est ignorée avec les formats binaires. Pour ces formats, vous pouvez spécifier l'option à l'appel de pg_restore.

La sortie débute par une commande de création de la base de données et de connexion à cette base. Peu importe, dans ce cas, la base de données de connexion à la restauration. De plus, si --clean est aussi spécifié, le script supprime puis crée de nouveau la base de données cible avant de s'y connecter.

Cette option est ignorée avec les formats binaires. Pour ces formats, vous pouvez spécifier l'option à l'appel de pg_restore.

La sortie est redirigée vers le fichier indiqué. Ce paramètre peut être omis pour les sorties en mode fichier, dans ce cas la sortie standard sera utilisée. Par contre, il doit être fourni pour le format 'directory' (répertoire), où il spécifie le répertoire cible plutôt qu'un fichier. Dans ce cas, le répertoire est créé par pg_dump et ne doit pas exister auparavant.

La sauvegarde est créée dans l'encodage indiqué. Par défaut, la sauvegarde utilise celui de la base de données. Le même résultat peut être obtenu en positionnant la variable d'environnement PGCLIENTENCODING avec le codage désiré pour la sauvegarde.

Le format de la sortie. format correspond à un des éléments suivants :

Exécute une sauvegarde parallélisée en sauvegardant njobs tables simultanément. Cette option réduit la durée de la sauvegarde mais elle augmente aussi la charge sur le serveur de base de données. Vous ne pouvez utiliser cette option qu'avec le format de sortie répertoire car c'est le seul format où plusieurs processus peuvent écrire leur données en même temps.

pg_dump ouvrira njobs + 1 connexions à la base de données. Assurez-vous donc que la valeur de max_connections est configurée suffisamment haut pour permettre autant de connexions.

Réclamer des verrous exclusifs sur les objets de la base lors de l'exécution d'une sauvegarde parallélisée peut causer l'échec de la sauvegarde. La raison en est que le processus maître de pg_dump réclame des verrous partagés sur les objets que les processus fils vont sauvegarder plus tard pour s'assurer que personne ne les supprime pendant la sauvegarde. Si un autre client demande alors un verrou exclusif sur une table, ce verrou ne sera pas accepté mais mis en queue, en attente du relâchement du verrou partagé par le processus maître. En conséquence, tout autre accès à la table ne sera pas non plus accepté. Il sera lui-aussi mis en queue, après la demande de verrou exclusif. Cela inclut le processus fils essayant de sauvegarder la table. Sans autre précaution, cela résulterait en un classique « deadlock ». Pour détecter ce conflit, le processus fils pg_dump réclame un nouveau verrou partagé en utilisant l'option NOWAIT. Si le processus fils n'obtient pas ce verrou, quelqu'un d'autre doit avoir demandé un verrou exclusif entre temps, et il n'existe donc aucun moyen de continuer la sauvegarde. pg_dump n'a d'autre choix que d'annuler la sauvegarde.

Pour réaliser une sauvegarde cohérente, le serveur de la base de données a besoin de supporter les images (« snapshots ») synchronisées. Cette fonctionnalité a été introduite avec PostgreSQL™ 9.2. Avec cette fonctionnalité, les clients de la base de données peuvent s'assurer de voir le même ensemble de données, même s'ils utilisent des connexions différentes. pg_dump -j utilise plusieurs connexions à la base de données ; il se connecte une première fois en tant que processus maître et une fois encore par processus fils. Sans la fonctionnalité d'images synchronisées, les différent processus ne pourraient pas garantir de voir les mêmes données sur chaque connexion, ce qui aurait pour résultat une sauvegarde incohérente.

Si vous voulez exécuter une sauvegarde parallélisée à partir d'un serveur antérieur à la version 9.2, vous devez vous assurer que le contenu de la base ne change pas entre le moment où le maître se connecte à la base de données et celui où le dernier processus fils se connecte à la même base de données. La façon la plus simple est de mettre en pause tout processus de modification (DDL et DML) qui a eu accès à la base avant le début de la sauvegarde. Vous aurez besoin d'utiliser l'option --no-synchronized-snapshots si vous exécutez pg_dump -j sur une version de PostgreSQL™ antérieure à la 9.2. server.

Sauvegarde uniquement les schémas correspondant à schema ; la sélection se fait à la fois sur le schéma et sur les objets qu'il contient. Quand cette option n'est pas indiquée, tous les schémas non système de la base cible sont sauvegardés. Plusieurs schémas peuvent être indiqués en utilisant plusieurs fois l'option -n. De plus, le paramètre schéma est interprété comme un modèle selon les règles utilisées par les commandes \d de psql (voir la section intitulée « motifs »). Du coup, plusieurs schémas peuvent être sélectionnés en utilisant des caractères joker dans le modèle. Lors de l'utilisation de ces caractères, il faut faire attention à placer le modèle entre guillemets, si nécessaire, pour empêcher le shell de remplacer les jokers; see Exemples.

Note

Quand -n est indiqué, pg_dump ne sauvegarde aucun autre objet de la base que ceux dont les schémas sélectionnés dépendent. Du coup, il n'est pas garanti que la sauvegarde d'un schéma puisse être restaurée avec succès dans une base vide.

Note

Les objets qui ne font pas partie du schéma comme les objets larges ne sont pas sauvegardés quand -n est précisé. Ils peuvent être rajouter avec l'option --blobs.

Ne sauvegarde pas les schémas correspondant au modèle schéma. Le modèle est interprété selon les même règles que -n. -N peut aussi être indiqué plus d'une fois pour exclure des schémas correspondant à des modèles différents.

Quand les options -n et -N sont indiquées, seuls sont sauvegardés les schémas qui correspondent à au moins une option -n et à aucune option -N. Si -N apparaît sans -n, alors les schémas correspondant à -N sont exclus de ce qui est une sauvegarde normale.

Les identifiants d'objets (OID) sont sauvegardés comme données des tables. Cette option est utilisée dans le cas d'applications utilisant des références aux colonnes OID (dans une contrainte de clé étrangère, par exemple). Elle ne devrait pas être utilisée dans les autres cas.

Les commandes d'initialisation des possessions des objets au regard de la base de données originale ne sont pas produites. Par défaut, pg_dump engendre des instructions ALTER OWNER ou SET SESSION AUTHORIZATION pour fixer ces possessions. Ces instructions échouent lorsque le script n'est pas lancé par un superutilisateur (ou par l'utilisateur qui possède tous les objets de ce script). L'option -O est utilisée pour créer un script qui puisse être restauré par n'importe quel utilisateur. En revanche, c'est cet utilisateur qui devient propriétaire de tous les objets.

Cette option est ignorée avec les formats binaires. Pour ces formats, vous pouvez spécifier l'option à l'appel de pg_restore.

Cette option, obsolète, est toujours acceptée pour des raisons de compatibilité ascendante.

Seule la définition des objets (le schéma) est sauvegardée, pas les données.

Cette option est l'inverse de --data-only. Elle est similaire, mais pas identique (pour des raisons historiques), à --section=pre-data --section=post-data.

(Ne pas la confondre avec l'option --schema qui utilise le mot « schema » dans un contexte différent.)

Pour exclure les données de la table pour seulement un sous-ensemble des tables de la base de données, voir --exclude-table-data.

Le nom du superutilisateur à utiliser lors de la désactivation des déclencheurs. Cela n'a d'intérêt que si l'option --disable-triggers est précisée. (En règle générale, il est préférable de ne pas utiliser cette option et de lancer le script produit en tant que superutilisateur.)

Sauvegarde uniquement les tables (ou vues ou séquences or tables distantes) correspondant à table. Plusieurs tables sont sélectionnables en utilisant plusieurs fois l'option -t. De plus, le paramètre table est interprété comme un modèle suivant les règles utilisées par les commandes \d de psql (voir la section intitulée « motifs »). Du coup, plusieurs tables peuvent être sélectionnées en utilisant des caractères joker dans le modèle. Lors de l'utilisation de ces caractères, il faut faire attention à placer le modèle entre guillemets, si nécessaire, pour empêcher le shell de remplacer les jokers; see Exemples.

Les options -n et -N n'ont aucun effet quand l'option -t est utilisée car les tables sélectionnées par -t sont sauvegardées quelle que soit la valeur des options relatives aux schémas. Les objets qui ne sont pas des tables ne sont pas sauvegardés.

Note

Quand -t est indiqué, pg_dump ne sauvegarde aucun autre objet de la base dont la (ou les) table(s) sélectionnée(s) pourrai(en)t dépendre. Du coup, il n'est pas garanti que la sauvegarde spécifique d'une table puisse être restaurée avec succès dans une base vide.

Note

Le comportement de l'option -t n'est pas entièrement compatible avec les versions de PostgreSQL™ antérieures à la 8.2. Auparavant, écrire -t tab sauvegardait toutes les tables nommées tab, mais maintenant, seules sont sauvegardées celles qui sont visibles dans le chemin de recherche des objets. Pour retrouver l'ancien comportement, il faut écrire -t '*.tab'. De plus, il faut écrire quelque chose comme -t sch.tab pour sélectionner une table dans un schéma particulier plutôt que l'ancienne syntaxe -n sch -t tab.

Ne sauvegarde pas les tables correspondant au modèle table. Le modèle est interprété selon les même règles que -t. -T peut aussi être indiqué plusieurs pour exclure des tables correspondant à des modèles différents.

Quand les options -t et -T sont indiquées, seules sont sauvegardées les tables qui correspondent à au moins une option -t et à aucune option -T. Si -T apparaît sans -t, alors les tables correspondant à -T sont exclues de ce qui est une sauvegarde normale.

Mode verbeux. pg_dump affiche des commentaires détaillés sur les objets et les heures de début et de fin dans le fichier de sauvegarde. Des messages de progression sont également affichés sur la sortie d'erreur standard.

Affiche la version de pg_dump puis quitte.

Les droits d'accès (commandes grant/revoke) ne sont pas sauvegardés.

Indique le niveau de compression à utiliser. Zéro signifie sans compression. Pour le format d'archive personnalisé et le format répertoire, cela signifie la compression des segments individuels des données des tables. Par défaut, la compression se fait à un niveau modéré. Pour le format texte, indiquer une valeur différente de zéro implique une compression du fichier complet, comme s'il était passé à gzip ; mais par défaut, la sortie n'est pas compressée. Le format d'archive tar ne supporte pas du tout la compression.

Cette option est destinée à être utilisée pour une mise à jour en ligne. Son utilisation dans d'autres buts n'est ni recommandée ni supportée. Le comportement de cette option peut changer dans les futures versions sans avertissement.

Extraire les données en tant que commandes INSERT avec des noms de colonnes explicites (INSERT INTO table (colonne, ...) VALUES ...). Ceci rendra la restauration très lente ; c'est surtout utile pour créer des extractions qui puissent être chargées dans des bases de données autres que PostgreSQL™.

Cette option désactive l'utilisation du caractère dollar comme délimiteur de corps de fonctions, et force leur délimitation en tant que chaîne SQL standard.

Cette option ne s'applique que dans le cas d'une extraction de données seules. Ceci demande à pg_dump d'inclure des commandes pour désactiver temporairement les triggers sur les tables cibles pendant que les données sont rechargées. Utilisez ceci si, sur les tables, vous avez des contraintes d'intégrité ou des triggers que vous ne voulez pas invoquer pendant le rechargement.

À l'heure actuelle, les commandes émises pour --disable-triggers doivent être exécutées en tant que superutilisateur. Par conséquent, vous devez aussi spécifier un nom de superutilisateur avec -S, ou préférablement faire attention à lancer le script résultat en tant que superutilisateur.

Cette option est ignorée avec les formats binaires. Pour ces formats, vous pouvez spécifier l'option à l'appel de pg_restore.

Cette option est seulement adéquate lors de la sauvegarde du contenu d'une table disposant du mode de sécurité niveau ligne. Par défaut, pg_dump configurera row_security à off pour s'assurer que toutes les données de la table soient sauvegardées. Si l'utilisateur n'a pas les droits suffisant pour contourner la sécurité niveau ligne, alors une erreur est renvoyée. Ce paramètre force pg_dump à configurer row_security à on, permettant à l'utilisateur de ne sauvegarder que le contenu auquel il a le droit d'accéder.

Notez que si vous utilisez cette option actuellement, vous serez certainement intéressé à faire une sauvegarde au format INSERT car les politiques de sécurité ne sont pas respectées par l'instruction COPY FROM.

Ne sauvegarde pas les données pour toute table correspondant au motif indiqué par table. Le motif est interprété selon les même règles que pour l'option -t. --exclude-table-data peut être utilisé plusieurs fois pour exclure des tables dont le nom correspond à des motifs différents. Cette option est utile quand vous avez besoin de la définition d'une table particulière mais pas de ses données.

Pour exclure les données de toutes les tables de la base, voir --schema-only.

Utilise des commandes conditionnelles (c'est-à-dire des clauses IF EXISTS) lors du nettoyage (suppression) des objets de la base. Cette option n'est pas valide à moins que --clean ne soit également spécifié.

Extraire les données en tant que commandes INSERT (plutôt que COPY). Ceci rendra la restauration très lente ; c'est surtout utile pour créer des extractions qui puissent être chargées dans des bases de données autres que PostgreSQL™. Notez que la restauration peut échouer complètement si vous avez changé l'ordre des colonnes. L'option --column-inserts est plus sûre, mais encore plus lente.

Ne pas attendre indéfiniment l'acquisition de verrous partagés sur table au démarrage de l'extraction. Échouer à la place s'il est impossible de verrouiller une table dans le temps d'expiration indiqué. L'expiration peut être spécifiée dans tous les formats acceptés par SET statement_timeout, les valeurs autorisées dépendant de la version du serveur sur laquelle vous faites l'extraction, mais une valeur entière en millisecondes est acceptée par toutes les versions depuis la 7.3. Cette option est ignorée si vous exportez d'une version antérieure à la 7.3.

Ne sauvegarde pas les labels de sécurité.

Cette option permet l'exécution de pg_dump -j sur un serveur de version antérieure à la 9.2. Voir la documentation sur le paramètre -j pour plus de détails.

Ne pas générer de commandes pour créer des tablespace, ni sélectionner de tablespace pour les objets. Avec cette option, tous les objets seront créés dans le tablespace par défaut durant la restauration.

Cette option est ignorée avec les formats binaires. Pour ces formats, vous pouvez spécifier l'option à l'appel de pg_restore.

Ne pas exporter le contenu des tables non journalisées (unlogged). Cette option n'a aucun effet sur le fait que la définition (schéma) des tables soit exportée ou non; seul l'export des données de la table est supprimé. Les données des tables non journalisées sont toujours exclues lors d'une sauvegarde à partir d'un serveur en standby.

Force la mise entre guillemets de tous les identifiants. Ceci peut être utile si vous exportez votre base en vue d'une migration dans une nouvelle version qui aurait introduit de nouveaux mots clés.

Sauvegarde seulement la section nommée. Le nom de la section peut être pre-data, data ou post-data. Cette option peut être spécifiée plus d'une fois pour sélectionner plusieurs sections. La valeur par défaut est toutes les sections.

La section data contient toutes les données des tables ainsi que la définition des Large Objects et les valeurs des séquences. Les éléments post-data incluent la définition des index, triggers, règles et constraintes (autres que les contraintes de vérification). Les éléments pre-data incluent en tous les autres éléments de définition.

Utiliser une transaction sérialisable pour l'export, pour garantir que l'instantané utilisé est cohérent avec les états futurs de la base; mais ceci est effectué par l'attente d'un point dans le flux des transactions auquel aucune anomalie ne puisse être présente, afin qu'il n'y ait aucun risque que l'export échoue ou cause l'annulation d'une autre transaction pour erreur de sérialisation. Voyez Chapitre 13, Contrôle d'accès simultané pour davantage d'informations sur l'isolation des transactions et le contrôle d'accès concurrent.

Cette option est inutile pour un dump qui ne sera utilisé qu'en cas de récupération après sinistre. Elle pourrait être utile pour un dump utilisé pour charger une copie de la base pour du reporting ou toute autre activité en lecture seule tandis que la base originale continue à être mise à jour. Sans cela, le dump serait dans un état incohérent avec l'exécution sérielle des transactions qui auront été finalement validées. Par exemple, si un traitement de type batch est exécuté, un batch pourrait apparaître comme terminé dans le dump sans que tous les éléments du batch n'apparaissent.

Cette option ne fera aucune différence si aucune transaction en lecture-écriture n'est active au lancement de pg_dupm. Si des transactions en lecture-écriture sont actives, le démarrage du dump pourrait être retardé pour une durée indéterminée. Une fois qu'il sera démarré, la performance est identique à celle d'un dump sans cette option.

Utilise l'image de base de données synchronisée spécifiée lors de la sauvegarde d'une base de données (voir Tableau 9.71, « Fonction de synchronisation de snapshot » pour plus de détails).

Cette option est utile lorsqu'il est nécessaire de synchroniser la sauvegarde avec un slot de réplication logique (voir Chapitre 46, Décodage logique (Logical Decoding)) ou avec une session concurrente.

Dans le cas d'une sauvegarde parallèle, le nom de l'image défini par cette option est utilisé plutôt que de prendre une nouvelle image de base.

Émettre des commandes SQL standard SET SESSION AUTHORIZATION à la place de commandes ALTER OWNER pour déterminer l'appartenance d'objet. Ceci rend l'extraction davantage compatible avec les standards, mais, suivant l'historique des objets de l'extraction, peut ne pas se restaurer correctement. Par ailleurs, une extraction utilisant SET SESSION AUTHORIZATION nécessitera certainement des droits superutilisateur pour se restaurer correctement, alors que ALTER OWNER nécessite des droits moins élevés.

Affiche l'aide sur les arguments en ligne de commande de pg_dump, puis quitte

Indique le nom de la base de données de connexion. Ceci revient à spécifier nom_base comme premier argument sans option sur la ligne de commande. Ce nom de base peut être remplacé par une chaîne de connexion. Dans ce cas, les paramètres de la chaîne de connexion surchargeront toutes les options en ligne de commande conflictuelles.

Le nom d'hôte de la machine sur laquelle le serveur de bases de données est exécuté. Si la valeur commence par une barre oblique (/), elle est utilisée comme répertoire pour le socket de domaine Unix. La valeur par défaut est fournie par la variable d'environnement PGHOST, si elle est initialisée. Dans le cas contraire, une connexion sur la socket de domaine Unix est tentée.

Le port TCP ou le fichier local de socket de domaine Unix sur lequel le serveur écoute les connexions. La valeur par défaut est fournie par la variable d'environnement PGPORT, si elle est initialisée. Dans le cas contraire, il s'agit de la valeur fournie à la compilation.

Le nom d'utilisateur utilisé pour la connexion.

Ne demande jamais un mot de passe. Si le serveur en réclame un pour l'authentification et qu'un mot de passe n'est pas disponible d'une autre façon (par exemple avec le fichier .pgpass), la tentative de connexion échouera. Cette option peut être utile pour les scripts où aucun utilisateur n'est présent pour saisir un mot de passe.

Force pg_dump à demander un mot de passe avant la connexion à une base de données.

Cette option n'est jamais nécessaire car pg_dump demande automatiquement un mot de passe si le serveur exige une authentification par mot de passe. Néanmoins, pg_dump perd une tentative de connexion pour tester si le serveur demande un mot de passe. Dans certains cas, il est préférable d'ajouter l'option -W pour éviter la tentative de connexion.

Spécifie un rôle à utiliser pour créer l'extraction. Avec cette option, pg_dump émet une commande SET ROLE nomrole après s'être connecté à la base. C'est utile quand l'utilisateur authentifié (indiqué par -U) n'a pas les droits dont pg_dump a besoin, mais peut basculer vers un rôle qui les a. Certaines installations ont une politique qui est contre se connecter directement en tant que superutilisateur, et l'utilisation de cette option permet que les extractions soient faites sans violer cette politique.

Paramètres de connexion par défaut.