IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

9.20. Fonctions d'administration système

Le Tableau 9.45, « Fonctions de paramétrage de configuration » affiche les fonctions disponibles pour connaître ou modifier les paramètres de configuration en exécution.


La fonction current_setting renvoie la valeur courante du paramètre nom_paramètre . Elle correspond à la commande SQL SHOW . Un exemple :

SELECT current_setting('datestyle');

 current_setting
-----------------
ISO, MDY
(1 row)

set_config configure le paramètre nom_paramètre avec nouvelle_valeur . Si est_locale vaut true, la nouvelle valeur s'appliquera seulement à la transaction en cours. Si vous voulez que la nouvelle valeur s'applique à la session en cours, utilisez false à la place. La fonction correspond à la commande SQL SET . Un exemple :

SELECT set_config('log_statement_stats', 'off', false);

 set_config
------------
off
(1 row)

Les fonctions montrées dans le Tableau 9.46, « Fonctions d'envoi de signal aux serveurs » envoient des signaux de contrôle aux autres processus serveur. L'utilisation de ces fonctions est restreinte aux superutilisateurs.


Chacune de ces fonctions renvoient true en cas de succès, false en cas d'échec.

pg_cancel_backend envoie un signal demandant l'annulation de la requête (SIGINT) à un processus serveur identifié par l'ID du processus. L'identifiant du processus d'un serveur actif peut se trouver à partir de la colonne procpid dans la vue pg_stat_activity ou en listant les processus postgres sur le serveur avec ps.

pg_reload_conf envoie un signal SIGHUP au serveur impliquant un nouveau chargement des fichiers de configuration pour tous les processus serveur.

pg_rotate_logfile signale au gestionnaire de journaux de trace de basculer immédiatement vers un nouveau fichier de sortie. Ceci fonctionne seulement quand redirect_stderr est utilisé pour les traces, sinon il n'y a pas de sous-processus de gestion des traces.

Les fonctions montrées dans le Tableau 9.47, « Fonctions de contrôle de la sauvegarde » aident à l'exécution de sauvegardes à chaud. L'utilisation d'une des trois premières fonctions est restreinte aux superutilisateurs.


pg_start_backup accepte un seul paramètre qui est un label défini arbitrairement par l'utilisateur pour la sauvegarde (typiquement, cela sera le nom sous lequel le fichier de sauvegarde sera stocké). La fonction écrit un fichier label dans le répertoire de données du groupe, puis renvoie le décalage du journal de transactions de début de sauvegarde au format texte (l'utilisateur n'a pas besoin de faire attention à la valeur du résultat mais il est fourni au cas où il pourrait être utile).

postgres=# select pg_start_backup('label_goes_here');
 pg_start_backup
-----------------
 0/D4445B8
(1 row)

pg_stop_backup supprime le fichier label créé par pg_start_backup et crée, à la place, un fichier historique dans l'emplacement des archives des journaux de transactions. Ce fichier inclut le label donné à pg_start_backup, les emplacements de début et de fin des journaux de transactions pour la sauvegarde ainsi que les heures de début et de fin de la sauvegarde. La valeur en retour est l'emplacement du journal de transactions de fin (qui a de nouveau peu d'intérêt). Après avoir noté l'emplacement de fin, le point d'insertion du journal de transactions actuel est automatiquement avancé au prochain journal de transactions, de façon à ce que le journal de transactions en fin de vie puisse être archivé immédiatement pour terminer la sauvegarde.

Pour des détails sur le bon usage de ces fonctions, voir la Section 23.3, « Archivage continu et récupération d'un instantané (PITR) ».

pg_switch_xlog déplace le prochain journal de transactions, permettant l'archivage du journal en cours (en supposant que vous utilisez l'archivage continu). Le résultat est l'emplacement de fin du journal de transaction à l'intérieur du journal de transaction tout juste terminé. S'il n'y a pas eu d'activité dans les journaux de transactions depuis le dernier changement des journaux de transactions, pg_switch_xlog ne fait rien et renvoie l'emplacement de fin du journal de transactions précédent.

pg_current_xlog_location affiche l'emplacement d'écriture du journal de transactions en cours dans le même format que celui utilisé dans les fonctions ci-dessus. De façon similaire, pg_current_xlog_insert_location affiche le point d'insertion du journal de transactions courant. Le point d'insertion est la fin « logique » du journal de transactions à tout instant alors que l'emplacement d'écriture est la fin de ce qui a déjà été écrit à partir des tampons internes du serveur. L'emplacement d'écriture est la fin de ce qui peut être examiné de l'extérieur du serveur et est habituellement ce que vous souhaitez si vous êtes intéressé dans l'archivage des journaux de transactions partiels. Le point d'insertion est rendu disponible principalement pour des raisons de débogage du serveur. Ce sont des opérations de lecture seule et ne nécessitent pas les droits du superutilisateur.

Vous pouvez utiliser pg_xlogfile_name_offset pour extraire le nom du journal de transactions correspondant et le décalage en octets à partir des résultats des fonctions ci-dessus. Par exemple :

postgres=# select * from pg_xlogfile_name_offset(pg_stop_backup());
        file_name         | file_offset 
--------------------------+-------------
 00000001000000000000000D |     4039624
(1 row)

De façon similaire, pg_xlogfile_name extrait seulement le nom du journal de transactions. Quand l'emplacement du journal de transactions donné est exactement sur une limite du journal de transactions, les deux fonctions renvoient le nom du journal de transactions précédent. C'est généralement le comportement souhaité pour gérer le comportement de l'archivage des journaux de transactions car le fichier précédent est le dernier qui a besoin d'être archivé.

Les fonctions montrées dans le Tableau 9.48, « Fonctions de calcul de taille des objets de la base de données » calculent l'utilisation de l'espace disque par les objets de la base de données.


pg_column_size affiche l'espace utilisé pour stocker toute valeur individuelle.

pg_database_size et pg_tablespace_size acceptent l'OID ou le nom d'une base de données ou d'un tablespace, et renvoient l'espace disque total utilisé.

pg_relation_size accepte l'OID ou le nom d'une table, d'un index ou d'une table toast, et renvoie la taille en octet.

pg_size_pretty peut être utilisé pour formater le résultat d'une des autres fonctions d'une façon lisible par un être humain, c'est-à-dire en utilisant kB, MB, GB ou TB lorsque cela est approprié.

pg_total_relation_size accepte l'OID ou le nom d'une table ou d'une table toast, et renvoie la taille en octets des données et de tous les index et tables toast associées.

Les fonctions montrées dans le Tableau 9.49, « Fonctions d'accès générique aux fichiers » fournissent un accès natif aux du serveur. Seuls les fichiers contenus dans le répertoire du groupe de la base de donénes et ceux du répertoire log_directory sont accessibles. Utilisez un chemin relatif pour les fichiers du répertoire du groupe et un chemin correspondant à la configuration du paramètre log_directory pour les journaux de trace. L'utilisation de ces fonctions sont restreintes aux superutilisateurs.


pg_ls_dir renvoie tous les noms du répertoire spécifié sauf les entrées spéciales «  .  » et «  ..  ».

pg_read_file renvoie une partie d'un fichier texte, débutant au décalage indiqué, renvoyant au plus longueur octets (moins si la fin du fichier est atteinte avant). Si le décalage est négatif, il est relatif à la fin du fichier.

pg_stat_file renvoie un enregistrement contenant la taille du fichier, la date et heure du dernier accès, la date et heure de la dernière modification, la date et heure du dernier changement de statut (plateformes Unix seulement), la date et heure de création (Windows seulement) et un booléen indiquant s'il s'agit d'un répertoire. Les usages typiques incluent :

SELECT * FROM pg_stat_file('nomfichier');
SELECT (pg_stat_file('nomfichier')).modification;

Les fonctions affichées dans Tableau 9.50, « Fonctions des verrous informatifs » gèrent les verrous informatifs. Pour les détails sur le bon usage de ces fonctions, voir Section 12.3.4, « Verrous informatifs ».


pg_advisory_lock verrouille une ressource définie par l'application qui peut être identifiée soit par une valeur de clé sur 64 bits soit par deux valeurs de clé sur 32 bits (notez que les deux espaces de clé ne se surchargent pas). Si une autre session détient déjà un verrou sur la même ressource, la fonction attendra jusqu'à ce que la ressource devienne disponible. Le verrou est exclusif. Les demandes de verrous s'empilent pour que, si une même ressource est verrouillée trois fois, elle doit être déverrouillée trois fois pour être disponible par les autres sessions.

pg_advisory_lock_shared fonctionne de façon identique à pg_advisory_lock sauf que le verrou peut être partagé avec d'autres sessions qui réclament des verrous partagés. Seuls les demandes de verrous exclusifs sont bloqués.

pg_try_advisory_lock est similaire à pg_advisory_lock sauf que la fonction n'attendra pas la disponibilité du verrou. Soit il obtiendra le verrou immédiatement et renverra true, soit il ne l'obtiendra pas et il renverra false.

pg_try_advisory_lock_shared fonctionne de la même façon que pg_try_advisory_lock sauf s'il tente d'acquérir un verrou partagé au lieu d'un verrou exclusif.

pg_advisory_unlock lâchera un verrou informatif exclusif précédemment acquis. Il renverra true si le verrou est relaché avec succès. Si le verrou n'était pas détenu, false sera renvoyé. De plus, un message d'avertissement SQL sera émis par le serveur.

pg_advisory_unlock_shared fonctionne de la même façon que pg_advisory_unlock sauf pour relacher un verrou informatif partagé.

pg_advisory_unlock_all relachera tous les verrous informatifs détenus par la session courante. (Cette fonction est appelée implicitement à la fin de la session, même si le client se déconnecte d'une mauvaise façon.)