9.28. Fonctions d'administration système #
Les fonctions décrites dans cette section sont utilisées pour contrôler
et superviser une installation PostgreSQL.
9.28.1. Fonctions de configuration #
Tableau 9.93 liste les fonctions
disponibles pour requêter et modifier les paramètres de
configuration.
Tableau 9.93. Fonctions de configuration
Fonction
Description
Exemple(s)
|
---|
current_setting ( setting_name text [, missing_ok boolean ] )
→ text
Renvoie la valeur actuelle du paramètre
setting_name . Si ce paramètre n'existe pas,
current_setting renvoie une erreur sauf si
missing_ok est renseigné et vaut
true (auquel cas NULL est renvoyé). Cette fonction
correspond à la commande SQL SHOW.
current_setting('datestyle')
→ ISO, MDY
|
set_config (
setting_name text ,
new_value text ,
is_local boolean )
→ text
Configure le paramètre setting_name à
new_value , et renvoie cette valeur. Si
is_local vaut true , la
nouvelle valeur s'appliquera uniquement durant la transaction en cours.
Si vous voulez que la nouvelle valeur s'applique pour le reste de la
session courante, utilisez false à la place. Cette
fonction correspond à la commande SQL SET.
set_config('log_statement_stats', 'off', false)
→ off
|
9.28.2. Fonctions d'envoi de signaux #
Les fonctions listées dans Tableau 9.94
envoient des signaux de contrôle aux autres processus serveur.
L'utilisation de ces fonctions est restreinte aux superutilisateurs par
défaut, mais un accès peut être fourni aux utilisateurs en utilisant la
commande GRANT
, avec quelques exceptions notables.
Chacune de ces fonctions renvoient true
si le signal
a bien été envoyé et false
si l'envoi du signal a échoué.
Tableau 9.94. Fonctions d'envoi de signaux
Fonction
Description
|
---|
pg_cancel_backend ( pid integer )
→ boolean
Annule la requête en cours de la session du processus serveur dont
l'identifiant de processus a été donné. Ceci est aussi autorisé si le
rôle appelant est un membre de pg_signal_backend .
Néanmoins, seuls les superutilisateurs peuvent annuler les processus
des superutilisateurs.
|
pg_log_backend_memory_contexts ( pid integer )
→ boolean
Demande le traçage des contextes mémoire du processus dont l'identifiant
est spécifié. Cette fonction doit envoyer la demande aux processus serveur
sauf le logger. Ces contextes mémoire seront tracés au niveau
LOG . Ils apparaîtront dans les traces du serveur selon
la configuration (voir Section 19.8 pour plus
d'informations), mais ne seront pas envoyés au client, comme indiqué dans
client_min_messages. Seul un superutilisateur peut
demander le traçage des contextes mémoire.
|
pg_reload_conf ()
→ boolean
Cause le rechargement des fichiers de configurations par tous les
processus du serveur PostgreSQL. (Ceci se
fait en envoyant un signal SIGHUP au
processus postmaster qui, à son tour, envoie un signal
SIGHUP à chacun de ses processus fils.)
Vous pouvez utiliser les vues
pg_file_settings et
pg_hba_file_rules
pg_ident_file_mappings
pour vérifier d'éventuelles erreurs dans les fichiers de configuration, avant leur rechargement.
|
pg_rotate_logfile ()
→ boolean
Signale au collecteur de traces qu'il doit changer de fichier de trace
immédiatement. Ceci fonctionne seulement quand le collecteur de trace
natif est en cours d'exécution.
|
pg_terminate_backend ( pid integer , timeout bigint DEFAULT 0 )
→ boolean
Termine la session pour le processus serveur dont l'identifiant de
processus a été donné. Ceci est aussi autorisé si le rôle appelant est
un membre du rôle dont le processus est en cours d'arrêt ou si le rôle
appelant est membre de pg_signal_backend .
Néanmoins, seuls les superutilisateurs peuvent terminer les processus
des superutilisateurs.
Si timeout n'est pas précisé ou vaut zéro, cette
fonction renvoie true , que le processus actuel
se termine ou pas, confirmant simplement l'envoi correct du signal.
Si timeout est précisé (en millisecondes)
et que sa valeur est supérieure à zéro, la fonction attend que le processus
se termine effectivement ou que le temps soit dépassé.
Si le processus est terminé, la fonction retourne
true . Si le temps est dépassé, un avertissement
est émis et la fonction retourne false .
|
pg_cancel_backend
et
pg_terminate_backend
envoient des signaux
(respectivement SIGINT et
SIGTERM) aux processus serveurs identifiés par
leur PID. Le PID d'un processus serveur actif est disponible dans la
colonne pid
de la vue
pg_stat_activity
ou en listant les processus
postgres
sur le serveur (en utilisant
ps sur Unix ou le Task
Manager sur Windows). Le rôle
d'un processus serveur actif est disponible dans la colonne
usename
de la vue
pg_stat_activity
.
pg_log_backend_memory_contexts
peut être utilisée
pour tracer les contextes mémoires de processus en arrière-plan. Par exemple :
postgres=# SELECT pg_log_backend_memory_contexts(pg_backend_pid());
pg_log_backend_memory_contexts
--------------------------------
t
(1 row)
Un message pour chaque contexte mémoire sera tracé. Par exemple :
LOG: logging memory contexts of PID 10377
STATEMENT: SELECT pg_log_backend_memory_contexts(pg_backend_pid());
LOG: level: 0; TopMemoryContext: 80800 total in 6 blocks; 14432 free (5 chunks); 66368 used
LOG: level: 1; pgstat TabStatusArray lookup hash table: 8192 total in 1 blocks; 1408 free (0 chunks); 6784 used
LOG: level: 1; TopTransactionContext: 8192 total in 1 blocks; 7720 free (1 chunks); 472 used
LOG: level: 1; RowDescriptionContext: 8192 total in 1 blocks; 6880 free (0 chunks); 1312 used
LOG: level: 1; MessageContext: 16384 total in 2 blocks; 5152 free (0 chunks); 11232 used
LOG: level: 1; Operator class cache: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used
LOG: level: 1; smgr relation table: 16384 total in 2 blocks; 4544 free (3 chunks); 11840 used
LOG: level: 1; TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used
...
LOG: level: 1; ErrorContext: 8192 total in 1 blocks; 7928 free (3 chunks); 264 used
LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560 used
S'il y a plus de 100 contextes fils sous le même parent, les 100 premiers
contextes fils sont tracés, le reste des contextes étant résumé.
Notez que des appels fréquents à cette fonction peut produire une surchage significative,
parce qu'elle génère un grand nombre de messages dans les traces.
9.28.3. Fonctions de contrôle de la sauvegarde #
Les fonctions listées dans Tableau 9.95
aident à la réalisation de sauvegardes en ligne. Ces fonctions ne peuvent
pas être exécutées lors de la restauration (sauf pour
pg_backup_start
,
pg_backup_stop
,
pg_wal_lsn_diff
).
Pour les détails sur l'utilisation correcte de ces fonctions, voir
Section 25.3.
Tableau 9.95. Fonctions de contrôle de la sauvegarde
Fonction
Description
|
---|
pg_create_restore_point ( name text )
→ pg_lsn
Crée un enregistrement marqueur nommé dans le journal de transactions.
Ce marqueur peut ensuite être utilisé comme cible de restauration et
renvoie l'emplacement correspondant dans le journal de transactions.
Le nom donné peut être utilisé avec recovery_target_name pour indiquer le point final de
restauration. Évitez de créer plusieurs points de restauration de même
nom car la restauration s'arrêtera au premier marqueur rencontré dont
le nom correspond à la cible de restauration.
Cette fonction est par défaut restreinte aux superutilisateurs mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_current_wal_flush_lsn ()
→ pg_lsn
Renvoie l'emplacement actuel de vidage du journal de transaction
(voir les notes ci-dessous).
|
pg_current_wal_insert_lsn ()
→ pg_lsn
Renvoie l'emplacement actuel d'insertion du journal de transaction
(voir les notes ci-dessous).
|
pg_current_wal_lsn ()
→ pg_lsn
Renvoie l'emplacement actuel d'écriture du journal de transaction
(voir les notes ci-dessous).
|
pg_backup_start (
label text
[, fast boolean
] )
→ pg_lsn
Prépare le serveur à commencer une sauvegarde en ligne. Le seul
paramètre requis est un label arbitraire défini par l'utilisateur.
(Typiquement, ce serait nom sous lequel le fichier de sauvegarde sera
stocké.) Si le deuxième paramètre optionnel est donné à
true , il demande l'exécution aussi rapide que
possible de pg_backup_start . Ceci force un
checkpoint immédiat ce qui va cause un pic dans les opérations
disques, ralentissant les requêtes en cours d'exécution.
Cette fonction est par défaut restreinte aux superutilisateurs mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_backup_stop (
[wait_for_archive boolean
] )
→ record
( lsn pg_lsn ,
labelfile text ,
spcmapfile text )
Termine l'exécution d'une sauvegarde en ligne. Le contenu désiré du
fichier de label et du fichier de correspondance des tablespaces est
renvoyé comme résultat de la fonction, et doit être écrit dans des
fichiers dans l'aire de sauvegarde. Ces fichiers ne doivent pas être
écrits dans le répertoire actuel des données (le faire pour causer l'échec
de redémarrage de PostgreSQL dans le cas d'un crash).
Il existe un paramètre optionnel de type
boolean . À false, la fonction se terminera immédiatement
après la fin de sauvegarde, sans attendre l'archivage des journaux de
transactions. Ce comportement est seulement utile pour les logiciels
de sauvegarde qui surveillent indépendamment l'archivage des journaux
de transactions. Sinon, les journaux requis pour rendre la sauvegarde
cohérente pourraient manquer et rendre la sauvegarde inutilisable. Par
défaut ou quand ce paramètre vaut true,
pg_backup_stop attendra l'archivage des journaux
de transactions si l'archivage est activé. (Sur un serveur secondaire,
cela signifie qu'elle attendra que si archive_mode
est configuré à always . Si l'activité en écriture
est faible sur le serveur primaire, il pourrait être utile d'exécuter
un pg_switch_wal sur le serveur primaire pour
forcer un changement de journal.)
Lors d'une exécution sur un serveur primaire, cette option crée aussi
un fichier d'historique de sauvegarde dans la zone d'archivage des
journaux de transactions. Le fichier d'historique inclut un label
donné par pg_backup_start , les emplacements de
début et de fin de la sauvegarde, et les dates et heures de début et
de fin de la sauvegarde. Après l'enregistrement de l'emplacement de
fin, le point d'insertion actuel dans les journaux de transactions est
automatiquement avancé au prochain journal, pour que le journal de fin
de sauvegarde soit immédiatement archivé pour terminer la sauvegarde.
Le résultat de la fonction est un simple enregistrement. La colonne
lsn détient l'emplacement de la fin de la
sauvegarde dans les journaux de transactions (qui peut de nouveau être
ignoré). La deuxième colonne renvoie le contenu du fichier de label, et la
troisième colonne le contenu du fichier de correspondance des tablespaces.
Elles doivent être enregistrées comme faisant partie de la sauvegarde et
sont requises pour le traitement de la restauration.
Cette fonction est par défaut restreinte aux superutilisateurs mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_switch_wal ()
→ pg_lsn
Force le serveur à utiliser un nouveau journal de transactions, ce qui
permet au journal actuel d'être archivé (en supposant que vous
utilisez l'archivage continu). Le résultat est l'emplacement de fin du
journal plus 1 dans le journal tout juste terminé. S'il n'y a pas eu
d'activité d'écriture depuis le dernier changement de journal,
pg_switch_wal ne fait rien et renvoie
l'emplacement de début du journal actuellement utilisé.
Cette fonction est par défaut restreinte aux superutilisateurs mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_walfile_name ( lsn pg_lsn )
→ text
Convertit un emplacement d'un journal de transaction par le nom du fichier
du journal de transaction détenant cet emplacement.
|
pg_walfile_name_offset ( lsn pg_lsn )
→ record
( file_name text ,
file_offset integer )
Convertit un emplacement d'un journal de transaction par le nom du fichier
du journal de transaction détenant cet emplacement et le décalage en octets
pour aller sur cet emplacement.
|
pg_split_walfile_name ( file_name text )
→ record
( segment_number numeric ,
timeline_id bigint )
Extrait le numéro de séquence et l'identifiant de timeline à partir du nom
d'un fichier WAL.
|
pg_wal_lsn_diff ( lsn1 pg_lsn , lsn pg_lsn2 )
→ numeric
Calcule la différence en octets (lsn1 -
lsn2 ) entre deux emplacements dans les journaux
de transactions. Cette fonction peut être utilisée avec
pg_stat_replication ou certaines des fonctions
listées dans Tableau 9.95 pour obtenir
le retard de réplication.
|
pg_current_wal_lsn
affiche l'emplacement actuel
d'écriture dans le journal de transaction en cours, dans le même format
que celui utilisé par les fonctions ci-dessus. De même,
pg_current_wal_insert_lsn
affiche l'emplacement
d'insertion actuel et pg_current_wal_flush_lsn
affiche l'emplacement de vidage actuel. L'emplacement d'insertion est la
fin « logiqie » du journal de transaction à n'importe quel
moment, alors que l'emplacement d'écriture est la fin de ce qui a été
réellement écrit à partir des caches internes du serveur, et l'emplacement
de vidage est le dernier emplacement connu pour avoir été réellement écrit
sur disque. L'emplacement d'écriture est la fin de ce qui doit être
examiné en dehors du serveur et est habituellement ce que vous voulez si
vous êtes intéressé par l'archivage des journaux partiellement complets.
Les emplacements d'insertion et de vidage sont rendus disponibles
principalement dans un but de débogage. Ce sont des opérations de lecture
seule et ne nécessite pas l'attribut superutilisateur.
Vous pouvez utiliser pg_walfile_name_offset
pour
extrait le nom du fichier et le décalage en octet du journal de
transaction correspondant à partir d'une valeur pg_lsn
. Par
exemple :
postgres=# SELECT * FROM pg_walfile_name_offset((pg_backup_stop()).lsn);
file_name | file_offset
--------------------------+-------------
00000001000000000000000D | 4039624
(1 row)
De la même façon, pg_walfile_name
extrait juste le
nom du fichier du journal de transactions.
pg_split_walfile_name
est utile pour calculer le
LSN à partir d'un déclage de fichier et du nom d'un
journal de transactions. Par exemple :
postgres=# \set file_name '000000010000000100C000AB'
postgres=# \set offset 256
postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset AS lsn
FROM pg_split_walfile_name(:'file_name') pd,
pg_show_all_settings() ps
WHERE ps.name = 'wal_segment_size';
lsn
---------------
C001/AB000100
(1 row)
9.28.4. Fonctions de contrôle de la restauration #
Les fonctions listées dans Tableau 9.96
fournissent des informations sur le statut actuel d'un serveur secondaire.
Ces fonctions peuvent être exécutées pendant une restauration et pendant
une exécution normale.
Tableau 9.96. Fonctions d'information sur la restauration
Fonction
Description
|
---|
pg_is_in_recovery ()
→ boolean
Renvoie true si la restauration est toujours en cours.
|
pg_last_wal_receive_lsn ()
→ pg_lsn
Renvoie le dernier emplacement des journaux de transactions, reçu et
synchronisé sur disque par la réplication en flux. Tant que la
réplication en flux est en cours, ceci augmentera de façon monotique.
Si la restauration s'est terminée, alors cela restera statique à
l'emplacement du dernier enregistrement reçu et synchronisé sur disque
lors de la restauration. Si la réplication en flux est désactivée ou
qu'elle n'a pas commencé, la fonction renvoie NULL .
|
pg_last_wal_replay_lsn ()
→ pg_lsn
Renvoie le dernier emplacement des journaux de transactions, rejoué
lors de la restauration. Si la restauration est toujours en cours,
ceci augmentera de façon monotique. Si la restauration s'est terminée,
alors cela restera statique à l'emplacement du dernier enregistrement
appliqué lors de la restauration. Quand le serveur a été démarré
normalement sans restauration, la fonction renvoie
NULL .
|
pg_last_xact_replay_timestamp ()
→ timestamp with time zone
Renvoie l'horodatage de la dernière transaction rejouée pendant la
restauration. C'est le moment où l'enregistrement de validation ou
d'annulation a été généré sur le serveur promaire. Si aucune
transaction n'a été rejouée pendant la restauration, la fonction
renvoie NULL . Sinon, si la restauration est
toujours en cours, ceci augmentera de façon monotonique. Si la
restauration s'est terminée, alors cela restera statique à partir du
moment de la dernière transaction appliquée à la restauration. Quand
le serveur est démarré normalement sans restauration, la fonction
renvoie NULL .
|
pg_get_wal_resource_managers ()
→ setof record
( rm_id integer ,
rm_name text ,
rm_builtin boolean )
Renvoie les gestionnaires de ressource WAL actuellement chargés dans le
système. La colonne rm_builtin indique s'il s'agit
d'un gestionnaire de ressources interne ou d'un gestionnaire de ressources
personnalisé chargé par une extension.
|
Les fonctions listées dans Tableau 9.97 contrôlent la progression de
la restauration. Ces fonctions peuvent seulement être exécutées lors d'une
restauration.
Tableau 9.97. Fonctions de contrôle de la restauration
Fonction
Description
|
---|
pg_is_wal_replay_paused ()
→ boolean
Renvoie true si la pause de la restauration est demandée.
|
pg_get_wal_replay_pause_state ()
→ text
Renvoie l'état de la pause de restauration. Les valeurs retournées
sont not paused si aucune pause n'est requise,
pause requested si une pause est requise,
mais que la restauration n'est pas en pause, et paused
si la restauration est effectivement en pause.
|
pg_promote ( wait boolean DEFAULT true , wait_seconds integer DEFAULT 60 )
→ boolean
Promeut un serveur secondaire au statut primaire. Avec
wait configuré à true (la
valeur par défaut), la fonction attend jusqu'à ce que la promotion
soit terminée ou jusqu'à ce que wait_seconds se
soient écoulées, et renvoie true si la promotion a
réussi. Elle renvoie false dans les autres cas. Si
wait est configuré à false ,
la fonction renvoie true immédiatement après avoir
envoyé le signal SIGUSR1 au postmaster pour
déclencher sa promotion.
Cette fonction est par défaut restreinte aux superutilisateurs mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_wal_replay_pause ()
→ void
Demande la mise en pause de la restauration. Une demande ne signifie pas
que la restauration va effectivement s'arrêter. Si vous voulez vérifier
que la restauration s'est effectivement arrêtée, vous devez vérifier
l'état de la pause de restauration retournée par
pg_get_wal_replay_pause_state() . Notez que
pg_is_wal_replay_paused() retourne si oui ou non une
demande est faite. Pendant que la restauration est en pause, plus aucune
modification ne peut être faite sur la base de données. Si aucun hot
standby n'est actif, toutes les requêtes verront le même instantané
consistant de la base de données, et plus aucun conflit de requête ne sera
généré jusqu'à ce que la restauration redémarre.
Cette fonction est par défaut restreinte aux superutilisateurs, mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_wal_replay_resume ()
→ void
Relance la restauration si elle était en pause.
Cette fonction est par défaut restreinte aux superutilisateurs mais
les autres utilisateurs peuvent se voir donner le droit EXECUTE pour
exécuter cette fonction.
|
pg_wal_replay_pause
et
pg_wal_replay_resume
ne peuvent pas être exécutés
quand une promotion est en cours. Si une promotion est déclenchée alors
que la restauration est en pause, l'état de pause se termine et la
promotion continue.
Si la réplication en flux est désactivé, l'état de pause peut continuer
indéfiniment sans problème. Si la réplication en flux est en cours, alors
les enregistrements des journaux de transactions continuent à être rçus,
ce qui finira par remplir l'espace disque disponible, suivant la durée de
la pause, le taux de génération des journaux de transactions et l'espace
disque disponible.
9.28.5. Fonctions de synchronisation d'image #
PostgreSQL permet aux sessions des bases de
données de synchroniser leur image de base. Une image de base (ou
snapshot) détermine les données visibles pour la
transaction utilisant l'image. Les images synchronisées sont nécessaires
quand deux sessions ou plus ont besoin de voir un contenu identique de la
base de données. Si deux sessions démarrent leur transaction
indépendamment, il existe toujours une possibilité qu'une autre
transaction valid entre l'exécution des deux commandes START
TRANSACTION
, de telle façon qu'une session voit l'effet de cette
transaction alors que l'autre ne la voit pas.
Pour résoudre ce problème, PostgreSQL autorise
une transaction à exporter l'image qu'elle utilise.
Tant que la transaction exportée reste ouverte, les autres transactions
peuvent importer son image et, de ce fait, garantir
qu'elles partagent exactement la même vue de la base que la première
transaction. Mais notez que tout changement effectué par une de ces
transactions reste invisible aux autres transactions, comme d'habitude
pour les modifications réalisées par des transactions non validées. Donc
les transactions sont synchronisées suivant les données pré-existantes,
mais agissent normalement pour les modifications qu'elles réalisent.
Les images sont exportées avec la fonction
pg_export_snapshot
, affichée dans Tableau 9.98, et importées avec la
commande SET TRANSACTION.
Tableau 9.98. Fonctions de synchronisation d'image
Fonction
Description
|
---|
pg_export_snapshot ()
→ text
Sauvegarde l'image actuelle de la transaction et renvoie une donnée de
type text identifiant l'image. Cette chaîne doit être
fournie (en dehors de la base) aux clients qui veulent importer
l'image. L'image est disponible à l'import seulement jusqu'à la fin de
la transaction qui l'a exporté.
Une transaction peut exporter plus d'une image, si nécessaire. Notez
que faire cela n'est utile que pour les transactions en niveau
READ COMMITTED car, dans les niveaux d'isolation
REPEATABLE READ et supérieurs, les transactions
utilisent la même image tout au long de leur vie. Une fois qu'une
transaction a export une image, elle ne peut pas être préparée avec
PREPARE TRANSACTION.
|
pg_log_standby_snapshot ()
→ pg_lsn
Prend une image des transactions en cours et les écrit dans les WAL,
sans attendre que le bgwriter ou le checkpointer le fassent. C'est utile
pour le décodage logique sur un standby, car la création d'un slot logique
doit attendre qu'un tel enregistrement soit rejoué sur le secondaire.
|
9.28.6. Fonctions de gestion de la réplication #
Les fonctions listées dans Tableau 9.99
sont pour le contrôle et l'interaction avec les fonctionnalités de
réplication. Voir Section 26.2.5, Section 26.2.6 et Chapitre 48 pour des informations sur les
fonctionnalités sous-jacentes. L'utilisation de fonctions pour l'origine
de réplication est seulement autorisée aux superutilisateurs par défaut,
mais peut être autorisée aux autres utilisateurs en utilisant la commande
GRANT
. L'utilisation des fonctions pour les slots de
réplication est restreinte aux superutilisateurs et aux utilisateurs ayant
l'attribut REPLICATION
.
La plupart de ces fonctions ont des commandes équivalentes dans le
protocole de réplication ; voir Section 53.4.
Les fonctions décrites dans
Section 9.28.3,
Section 9.28.4 et
Section 9.28.5
sont aussi adéquates pour la réplication.
Tableau 9.99. Fonctions de gestion de la réplication
Fonction
Description
|
---|
pg_create_physical_replication_slot ( slot_name name [, immediately_reserve boolean , temporary boolean , twophase boolean ] )
→ record
( slot_name name ,
lsn pg_lsn )
Crée un nouveau slot de réplication physique nommé
slot_name . Le deuxième paramètre, optionnel,
indique, quand il vaut true , que le
LSN pour ce slot de réplication doit être réservé
immédiatement. Dans le cas contraire, le LSN est
réservé lors de la première connexion à partir d'un client de
réplication de flux. Les changements en flux d'un slot de réplication
sont seulement possible avec le protocole de réplication de flux
-- voir Section 53.4. Le troisième
argument, optionnel, nommé temporary , indique,
quand il vaut true, que le slot ne doit pas être enregistré de façon
permanente sur disque et qu'il a seulement pour but d'être utilisé
dans la session en cours. Les slots temporaires sont aussi supprimés
dès qu'une erreur survient. Le quatrième paramètre optionnel,
twophase , quand il vaut true, indique
que le décodage des transactions préparées est autorisé pour ce
slot. Cette fonction correspond à la commande
CREATE_REPLICATION_SLOT ... PHYSICAL du protocole
de réplication.
|
pg_drop_replication_slot ( slot_name name )
→ void
Supprime le slot de réplication physique ou logique nommé
slot_name . Elle est identique à la commande
DROP_REPLICATION_SLOT du protocole de réplication.
Pour les slots logiques, elle doit être appelée en étant connecté sur
la même base que celle du slot de réplication.
|
pg_create_logical_replication_slot ( slot_name name , plugin name [, temporary boolean , twophase boolean , failover boolean ] )
→ record
( slot_name name ,
lsn pg_lsn )
Crée un nouveau slot de réplication logique (décodage) nommé
slot_name en utilisant le plugin de sortie
plugin . Le troisième paramètre, optionnel, nommé
temporary indique, quand il vaut true, que le
slot ne devrait pas être stockée de façon permanente sur disque et a
seulement pour but d'être utilisé par la session en cours. Les slots
temporaires sont aussi supprimés en cas d'erreur. Le cinquième
paramètre optionnel, failover , lorsqu'il vaut
true, spécifie que cet emplacement est activé pour être synchronisé
avec les serveurs de secours afin que la réplication logique puisse
reprendre après un basculement. Un appel à cette fonction a le même
effet que la commande CREATE_REPLICATION_SLOT ...
LOGICAL du protocole de réplication.
|
pg_copy_physical_replication_slot ( src_slot_name name , dst_slot_name name [, temporary boolean ] )
→ record
( slot_name name ,
lsn pg_lsn )
Copie un slot de réplication physique existant, nommé
src_slot_name , en un slot de réplication
physique nommé dst_slot_name . Le slot physique
copié commencera à réserver les journaux de transactions à partir du
même LSN que celui du slot copié. Le paramètre
temporary est en option. Si
temporary est omis, la valeur du slot source
est utilisée.
|
pg_copy_logical_replication_slot ( src_slot_name name , dst_slot_name name [, temporary boolean [, plugin name ]] )
→ record
( slot_name name ,
lsn pg_lsn )
Copie un slot existant de réplication logique nommé named
src_slot_name en un slot de réplication logique
nommé dst_slot_name , en changeant en option son
plugin de sortie et sa persistence. Le slot logique copié commence à
partir du même LSN que celui du slot logique
source. Les paramètres temporary et
plugin sont optionnels ; s'ils sont omis,
leur valeur sur le slot source est utilisée.
|
pg_logical_slot_get_changes ( slot_name name , upto_lsn pg_lsn , upto_nchanges integer , VARIADIC options text[] )
→ setof record
( lsn pg_lsn ,
xid xid ,
data text )
Renvoie les changements dans le slot slot_name ,
en commençant à partir du point où les changements ont été consommés
en dernier. Si upto_lsn et
upto_nchanges sont NULL, le décodage logique
continuera jusqu'à la fin des journaux de transactions. Si
upto_lsn n'est pas NULL, le décodage incluera
seulement les transactions dont la validation date d'avant le LSN
indiqué. Si upto_nchanges n'est pas NULL, le
décodage stoppera quand le nombre de lignes produites par le décodage
dépasse la valeur indiquée. Cependant, notez que le nombre réel de
lignes renvoyées pourrait être plus important car cette limite est
seulement vérifiée après l'ajout des lignes produites lors du décodage
de chaque nouvelle validation de transaction.
Si le slot spécifié est un slot de bascule logique, la fonction ne
renverra pas de résultat tant que tous les slots physiques spécifiés
dans synchronized_standby_slots
n'auront pas confirmé la réception du WAL
|
pg_logical_slot_peek_changes ( slot_name name , upto_lsn pg_lsn , upto_nchanges integer , VARIADIC options text[] )
→ setof record
( lsn pg_lsn ,
xid xid ,
data text )
Se comporte comme la fonction
pg_logical_slot_get_changes() , sauf que les
changements ne sont pas consommés ; autrement dit, ils sont de
nouveau renvoyés lors des prochains appels.
|
pg_logical_slot_get_binary_changes ( slot_name name , upto_lsn pg_lsn , upto_nchanges integer , VARIADIC options text[] )
→ setof record
( lsn pg_lsn ,
xid xid ,
data bytea )
Se comporte comme la fonction
pg_logical_slot_get_changes() , sauf que les
changements sont renvoyés comme des bytea .
|
pg_logical_slot_peek_binary_changes ( slot_name name , upto_lsn pg_lsn , upto_nchanges integer , VARIADIC options text[] )
→ setof record
( lsn pg_lsn ,
xid xid ,
data bytea )
Se comporte comme la fonction
pg_logical_slot_peek_changes() , sauf que les
modifications sont renvoyées sous la forme de bytea .
|
pg_replication_slot_advance ( slot_name name , upto_lsn pg_lsn )
→ record
( slot_name name ,
end_lsn pg_lsn )
Avance la position confirmée actuelle pour le slot de réplication
nommé slot_name . Le slot ne sera pas déplacé en
arrière, et il ne sera pas déplacé après l'emplacement d'insertion
actuel. Renvoie le nom du slot et la position où il a été réellement
avancé. L'information mise à jour de position du slot est écrite dans
le prochain checkpoint si l'avance a été possible. Dans le cas d'un
crash, le slot pourrait retourner à une position précédente.
Si le slot spécifié est un slot de bascule logique, la fonction ne
renverra pas de résultat tant que tous les slots physiques spécifiés
dans
synchronized_standby_slots
n'auront pas confirmé la réception du WAL
|
pg_replication_origin_create ( node_name text )
→ oid
Crée une origine de réplication avec le nom externe donné, et renvoie
l'identifiant interne qui lui a été affecté.
|
pg_replication_origin_drop ( node_name text )
→ void
Supprime une origine de réplication précédemment créée, incluant toute
progression de rejeu associée.
|
pg_replication_origin_oid ( node_name text )
→ oid
Recherche une origine de réplication par son nom et renvoie son
identifiant interne. Si cette origine de réplication n'existe pas,
NULL est renvoyée.
|
pg_replication_origin_session_setup ( node_name text )
→ void
Marque la session en cours comme rejouant à partir de l'origine
donnée, en autorisant le traçage de la progression du rejeu. Peut
seulement être utilisée si aucune origine n'est actuellement
sélectionnée. Utilisez
pg_replication_origin_session_reset pour annuler.
|
pg_replication_origin_session_reset ()
→ void
Annule les effets de
pg_replication_origin_session_setup() .
|
pg_replication_origin_session_is_setup ()
→ boolean
Renvoie true si une origine de réplication a été sélectionnée dans la
session en cours.
|
pg_replication_origin_session_progress ( flush boolean )
→ pg_lsn
Renvoie l'emplacement de rejeu pour l'origine de réplication
sélectionnée dans la session en cours. Le paramètre
flush détermine si la transaction locale
correspondance sera garantie d'être vidée sur disque ou pas.
|
pg_replication_origin_xact_setup ( origin_lsn pg_lsn , origin_timestamp timestamp with time zone )
→ void
Marque la transaction en cours comme rejouant une transaction qui a
été validée au LSN et à l'horodatage donnés. Peut
être appelé quand une origine de réplication a été sélectionnée en
utilisant pg_replication_origin_session_setup .
|
pg_replication_origin_xact_reset ()
→ void
Annule les effets de
pg_replication_origin_xact_setup() .
|
pg_replication_origin_advance ( node_name text , lsn pg_lsn )
→ void
Configure la progression de la réplication pour le nœud donné à
l'emplacement donné. Ceci est principalement utile pour configurer
l'emplacement initial ou pour configurer un nouvel emplacement après
des changements de configuration ou similaires. Faites attention
qu'une mauvaise utilisation de cette fonction peut amener à des
données répliquées de façon incohérente.
|
pg_replication_origin_progress ( node_name text , flush boolean )
→ pg_lsn
Renvoie l'emplacement de rejeu pour l'origine de réplication donnée.
Le paramètre flush détermine si la transaction
locale correspondante sera garantie d'être vidée sur disque ou pas.
|
pg_logical_emit_message ( transactional boolean , prefix text , content text [, flush boolean DEFAULT false ] )
→ pg_lsn
pg_logical_emit_message ( transactional boolean , prefix text , content bytea [, flush boolean DEFAULT false ] )
→ pg_lsn
Émet un message de décodage logique. Cela peut être utilisé pour
passer des messages génériques aux plugins de décodage logique via les
journaux de transactions. Le paramètre
transactional indique si le message devrait
faire partie de la transaction en cours ou s'il devrait être écrit
immédiatement et décodé dès que le décodeur logique lit
l'enregistrement. Le paramètre prefix est un
préfixe textuel qui peut être utilisé par les plugins de décodage
logique pour reconnaître facilement les messages qui les intéressent.
Le paramètre content est le contenu du message,
donné soit au format texte soit au format binaire.
Le paramètre flush (par défaut défini
à false ) contrôle si le message est immédiatement
vidé dans le WAL ou non. flush n'a aucun effet
avec transactional , car l'enregistrement WAL du
message est vidé en même temps que sa transaction.
|
pg_sync_replication_slots ()
→ void
Synchronise les slots de réplication logique de bascule du serveur
primaire vers le serveur secondaire. Cette fonction ne peut être
exécutée que sur le serveur secondaire. Les slots temporaires
synchronisés, le cas échéant, ne peuvent pas être utilisés pour le
décodage logique et doivent être supprimés après la promotion. Voir
Section 47.2.3
pour plus de détails. Notez que cette fonction ne peut pas être
exécutée si sync_replication_slots
est activé et si le worker de synchronisation des slots est déjà en
cours d'exécution pour réaliser la synchronisation des slots.
Attention
Si, après avoir exécuté la fonction,
hot_standby_feedback est désactivé sur le
serveur en attente ou si l'emplacement physique configuré dans primary_slot_name
est supprimé, alors il est possible que les lignes nécessaires du
slot synchronisé soient supprimées par le processus VACUUM sur le
serveur primaire, rendant ainsi le slot synchronisé invalide.
|
9.28.7. Fonctions de gestion des objets de la base #
Les fonctions listées dans Tableau 9.100
calculent l'utilisation de l'espace disque des objets de la base, ou
assistent dans la présentation ou la compréhension de ces résultats.
Les résultats du type bigint
correspondent à la
taille mesurée en octets. NULL
est renvoyé
si un OID qui ne représente pas un objet existant est fourni à une de ces
fonctions.
Tableau 9.100. Fonctions de taille des objets
Fonction
Description
|
---|
pg_column_size ( "any" )
→ integer
Affiche le nombre d'octets utilisés pour enregistrer une valeur
individuelle. Si elle est appliquée directement à une valeur d'une
colonne de la table, cela représente la compression effectuée.
|
pg_column_compression ( "any" )
→ text
Montre l'algorithme de compression utilisé pour compresser une
valeur individuelle. Retourne NULL
si la valeur n'est pas compressée.
|
pg_column_toast_chunk_id ( "any" )
→ oid
Affiche the chunk_id d'une valeur
TOAST sur disque. Renvoie NULL si
la valeur n'est pas un TOAST ou n'est pas sur disque.
Voir Section 65.2 pour plus d'informations sur
TOAST.
|
pg_database_size ( name )
→ bigint
pg_database_size ( oid )
→ bigint
Calcule l'espace disque total utilisé par la base dont le nom ou l'OID
est indiqué. Pour utiliser cette fonction, vous devez avoir le droit
CONNECT sur la base (qui est donné par défaut) ou
être un membre du rôle pg_read_all_stats .
|
pg_indexes_size ( regclass )
→ bigint
Calcule l'espace disque total utilisé par les index attachés à une
table spécifique.
|
pg_relation_size ( relation regclass [, fork text ] )
→ bigint
Calcule l'espace disque utilisé par un « élément » de la
relation indiquée. (Notez que, dans la plupart des cas, il est
préférable d'utiliser les fonctions
pg_total_relation_size et
pg_table_size , qui additionnent les tailles de
tous les éléments d'une relation.) Avec un argument, ceci renvoie la
taille de l'élément principal de la relation. Le second argument
permet de préciser l'élément à examiner :
main renvoie la taille de l'élément principal de
la relation.
fsm renvoie la taille de la carte des espaces
libres (voir Section 65.3) associée à cette
relation.
vm renvoie la taille de la carte de visibilité
(voir Section 65.4) associée à cette relation.
init renvoie la taille de l'élément
d'initialisation, si elle existe, associée à cette relation.
|
pg_size_bytes ( text )
→ bigint
Convertit la taille indiquée dans un format lisible par un humain
(tel qu'il est donné par pg_size_pretty ) en un
nombre d'octets. Les unités valides sont
bytes , B , kB ,
MB , GB , TB
et PB .
|
pg_size_pretty ( bigint )
→ text
pg_size_pretty ( numeric )
→ text
Convertit une taille indiquée en octets dans un format plus facilement
lisible par un humain avec des unités (bytes, kB, MB, GB, TB ou PB suivant
le cas). Notez que les unités sont des puissances de 2, plutôt que des
puissances de 10, donc 1kB vaut 1024 octets,
1MB vaut 10242 = 1048576 octets, et ainsi
de suite.
|
pg_table_size ( regclass )
→ bigint
Calcule l'espace disque utilisé par la table indiquée, en excluant les
index (mais en incluant la table TOAST si elle existe, la carte des
espaces libres et la carte de visibilité).
|
pg_tablespace_size ( name )
→ bigint
pg_tablespace_size ( oid )
→ bigint
Calcule l'espace disque total utilisé dans le tablespace indiqué par
son nom ou son OID. Pour utiliser cette fonction, vous devez avoir le
droit CREATE sur le tablespace ou être un membre du
rôle pg_read_all_stats , sauf s'il s'agit du
tablespace par défaut de la base actuelle.
|
pg_total_relation_size ( regclass )
→ bigint
Calcule l'espace disque utilisé par la table indiquée, en incluant
tous les index et les données TOAST. Le résultat
est équivalent à pg_table_size
+ pg_indexes_size .
|
Les fonctions ci-dessus qui opèrent sur les tables et sur les index acceptent
un argument regclass
, qui est simplement l'OID de la table ou
de l'index dans le catalogue système pg_class
.
Néanmoins, vous n'avez pas besoin de rechercher manuellement l'OID comme le
convertisseur en entrée du type de données regclass
fera ce
travail pour vous. Voir Section 8.19 pour les détails.
Les fonctions listées dans Tableau 9.101
assistent à l'identification des fichiers spécifiques associés aux objets
de la base.
Tableau 9.101. Fonctions d'emplacement des objets de la base
Fonction
Description
|
---|
pg_relation_filenode ( relation regclass )
→ oid
Renvoie le numéro « filenode » actuellement affecté à la
relation indiquée. Ce numéro est le composant de base du nom du
fichier utilisé pour la relation (voir Section 65.1 pour plus d'informations). Pour la
plupart des relations, le résultat est identique à
pg_class .relfilenode ,
mais pour certains catalogues systèmes, le
relfilenode vaut zéro et cette fonction
doit être utilisée pour obtenir la valeur correcte. La fonction
renvoie NULL si on lui passe une relation qui n'a pas de stockage,
comme une vue.
|
pg_relation_filepath ( relation regclass )
→ text
Renvoie le chemin complet avec le nom du fichier pour cette relation
(chemin relatif au répertoire principal des données de l'instance,
PGDATA ).
|
pg_filenode_relation ( tablespace oid , filenode oid )
→ regclass
Renvoie l'OID d'une relation d'après l'OID de son tablespace et son
filenode. Ceci est la correspondance inverse de
pg_relation_filepath . Pour une relation dans le
tablespace par défaut de la base, le tablespace peut être indiqué par
un zéro. Renvoie NULL si aucune relation n'est
associée aux valeurs données dans la base en cours.
|
Tableau 9.102 liste les fonctions utilisées
pour gérer les collations.
Tableau 9.102. Fonctions de gestion des collations
Fonction
Description
|
---|
pg_collation_actual_version ( oid )
→ text
Renvoie la version actuelle de l'objet collation tel qu'il est installé
sur le système d'exploitation. S'il est différent de la valeur dans
pg_collation .collversion ,
alors les objets dépendant de la collation doivent être reconstruits. Voir
aussi ALTER COLLATION.
|
pg_database_collation_actual_version ( oid )
→ text
Renvoie la version actuelle de la collation de la base de données tel
qu'elle est actuellement installée dans le système d'exploitation. Si c'est
différent de la valeur dans
pg_database .datcollversion ,
alors les objets dépendants de la collation pourraient avoir besoin d'être
reconstruits. Voir aussi ALTER DATABASE.
|
pg_import_system_collations ( schema regnamespace )
→ integer
Ajoute des collations dans le catalogue système
pg_collation basé sur toutes les locales
trouvées dans le système d'exploitation. Ceci est ce que
initdb utilise ; voir Section 23.2.2 pour plus de détails. Si les locales
supplémentaires sont installées plus tard dans le système
d'exploitation, cette fonction doit être de nouveau exécutée pour
ajouter des collations pour les nouvelles locales. Les locales
correspondant à des entrées existantes dans
pg_collation seront ignorées. (Mais les
objets de collation basés sur des locales qui ne sont plus présentes
au niveau du système d'exploitation ne sont pas supprimées par cette
fonction.) Le paramètre schema sera typiquement
pg_catalog , mais ce n'est pas obligatoire ;
les collations peuvent être installés dans d'autres schémas. La
fonction renvoie le nombre des nouveaux objets collations créés.
L'utilisation de cette fonction est restreinte aux superutilisateurs.
|
Tableau 9.103 liste les fonctions qui
fournissent des informations sur la structure des tables partitionnées.
Tableau 9.103. Fonctions d'information sur le partitionnement
Fonction
Description
|
---|
pg_partition_tree ( regclass )
→ setof record
( relid regclass ,
parentrelid regclass ,
isleaf boolean ,
level integer )
Liste les tables ou index dans l'arbre de partitionnement de la table
ou de l'index partitionné indiqué, avec une ligne pour chaque
partition. Les informations fournies incluent l'OID de la partition,
l'OID de son parent immédiat, une valeur booléenne indiquant si la
partition est une feuille et un entier indiquant son niveau dans la
hiérarchie. Le niveau 0 correspond à la table ou l'index en entrée, 1
pour ses partitions immédiates, 2, pour leurs partitions, et ainsi de
suite. Ne renvoie aucune ligne si la relation n'existe pas ou s'il ne
s'agit ni d'une table partitionnée ni d'une partition.
|
pg_partition_ancestors ( regclass )
→ setof regclass
Liste les relations ancêtres d'une partition donnée, y compris cette
relation. Ne renvoie aucune ligne si la relation n'existe pas ou s'il
ne s'agit ni d'une table partitionnée ni d'une partition.
|
pg_partition_root ( regclass )
→ regclass
Renvoie le parent de plus haut niveau de l'arbre de partition à
laquelle appartient la relation donnée. Renvoie
NULL si la relation n'existe pas ou s'il ne s'agit
ni d'une table partitionnée ni d'une partition.
|
Par exemple, pour vérifier la taille totale de la donnée contenue dans une
table partitionnée measurement
, il est possible
d'utiliser la requête suivante :
SELECT pg_size_pretty(sum(pg_relation_size(relid))) AS total_size
FROM pg_partition_tree('measurement');
9.28.8. Fonctions de maintenance des index #
Tableau 9.104 liste les fonctions
disponibles pour les tâches de maintenance d'index. (Notez que ces tâches
de maintenance sont normalement réalisés par l'autovacuum ;
l'utilisation de ces fonctions est seulement requise dans des cas
particuliers.) Ces fonctions ne peuvent pas être exécutées lors de la
restauration. L'utilisation de ces fonctions est restreinte aux
superutilisateurs et au propriétaire de l'index donné.
Tableau 9.104. Fonctions de maintenance des index
Fonction
Description
|
---|
brin_summarize_new_values ( index regclass )
→ integer
Parcourt l'index BRIN spécifié pour trouver les intervalles de blocs
da la table qui ne sont pas actuellement résumés par l'index ;
pour chaque intervalle, il crée un nouvel enregistrement de résumé
dans l'index en parcourant ces blocs dans la table. Renvoie le nombre
de nouveaux résumés d'intervalle de blocs insérés dans l'index.
|
brin_summarize_range ( index regclass , blockNumber bigint )
→ integer
Résume l'intervalle de blocs couvrant le bloc donné, s'il n'est pas
déjà résumé. Cela ressemble à
brin_summarize_new_values , sauf qu'il traite
seulement l'intervalle de blocs qui couvre le numéro de bloc de la
table donnée.
|
brin_desummarize_range ( index regclass , blockNumber bigint )
→ void
Supprime l'enregistement de l'index BRIN qui résume l'intervalle de
blocs couvrant le bloc de la table donnée, s'il y en a un.
|
gin_clean_pending_list ( index regclass )
→ bigint
Supprime la liste « pending » de l'index GIN spécifié en
déplaçant les enregistrements à l'intérieur, en masse, vers la
structure principale de données GIN. Renvoie le nombre de blocs
supprimés dans la liste d'attente. Si l'argument est un index GIN
construit avec l'option fastupdate désactivée,
aucun nettoyage ne survient et le résultat vaut zéro car l'index n'a
pas de liste d'attente. Voir Section 64.4.4.1 et
Section 64.4.5 pour les détails sur la liste d'attente et
l'option fastupdate .
|
9.28.9. Fonctions génériques d'accès aux fichiers #
Les fonctions listées dans Tableau 9.105
fournissent des accès natifs aux fichiers du serveur gérant le serveur.
Seuls les fichiers à l'intérieur du répertoire d'instance de la base et
ceux ciblés par le paramètre log_directory
peuvent être
accédés, que l'utilisateur est un superutilisateur ou s'est vu donné le
rôle pg_read_server_files
. Utilisez un chemin relatif
pour les fichiers du répertoire principal des données, et un chemin
correspondant à la configuration du paramètre
log_directory
pour les fichiers de trace.
Notez que donner aux utilisateurs le droit EXECUTE sur
pg_read_file()
, ou les fonctions relatives, les
autorise à lire tout fichier du serveur que le processus serveur peut
lire. Ces fonctions contournent toutes les vérifications de droit d'accès
à la base. Ceci signifie que, pour un exemple, un utilisateur avec un tel
accès est capable de lire le contenu de la table
pg_authid
où l'information d'authentification est
stockée dans les données de la table de la base. De ce fait, donner
l'accès à ces fonctions devrait être considéré avec attention.
Lors de l'octroi de droit sur ces fonctions, notez que les entrées des tables
affichant des paramètres optionnels sont principalement implémentées comme
plusieurs fonctions physiques avec des listes de paramètres différents. Le droit
doit être donné séparément pour chacune de ces fonctions, s'il doit être utilisé.
La commande \df
de psql peut
être utile pour vérifier les signatures réelles des fonctions.
Certaines de ces fonctions prennent un paramètre
missing_ok
qui modifie le comportement quand le
fichier ou le répertoire n'existe pas. Si true
, la
fonction renvoie NULL
ou un ensemble vide de résultats,
comme approprié. Si false
, une erreur est levée. (Les
conditions d'échec autres que « file not found » sont renvoyées
comme des erreurs dans tous les cas.) La
valeur par défaut est false
.
Tableau 9.105. Fonctions génériques d'accès aux fichiers
Fonction
Description
|
---|
pg_ls_dir ( dirname text [, missing_ok boolean , include_dot_dirs boolean ] )
→ setof text
Renvoie le nom de tous les fichiers (et répertoires et autres fichiers
spéciaux) dans le répertoire donné. Le paramètre
include_dot_dirs indique si les
pseudo-répertoires « . » et « .. » sont à
inclure dans le résultat ; par défaut, ils sont exclus. Les
inclure peut être utile dans missing_ok vaut
true pour distinguer un répertoire vide d'un
répertoire inexistant.
Cette fonction est restreinte par défaut aux superutilisateurs, mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
|
pg_ls_logdir ()
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification
de chaque fichier ordinaire dans le répertoire des traces du serveur.
Les fichiers dont le nom commence avec un point, les répertoires et
les autres fichiers spéciaux sont exclus.
Cette fonction est restreinte par défaut aux superutilisateurs et aux
utilisateurs membres du rôle pg_monitor , mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
|
pg_ls_waldir ()
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification
de chaque fichier ordinaire dans le répertoire des journaux de
transactions. Les fichiers dont le nom commence avec un point, les
répertoires et les autres fichiers spéciaux sont exclus.
Cette fonction est restreinte aux superutilisateurs et aux rôles ayant les
droits du rôle pg_monitor par défaut, mais les autres
utilisateurs peuvent se voir donner le droit EXECUTE pour exécuter la
fonction.
|
pg_ls_logicalmapdir ()
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification de
chaque fichier ordinaire dans le répertoire
pg_logical/mappings . Les fichiers dont le nom
commence avec un point, les répertoires et les autres fichiers spéciaux
sont exclus.
Cette fonction est restreinte aux superutilisateurs et aux rôles ayant les
droits du rôle pg_monitor par défaut, mais les autres
utilisateurs peuvent se voir donner le droit EXECUTE pour exécuter la
fonction.
|
pg_ls_logicalsnapdir ()
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification de
chaque fichier ordinaire dans le répertoire
pg_logical/snapshots . Les fichiers dont le nom
commence avec un point, les répertoires et les autres fichiers spéciaux
sont exclus.
Cette fonction est restreinte aux superutilisateurs et aux rôles ayant les
droits du rôle pg_monitor par défaut, mais les autres
utilisateurs peuvent se voir donner le droit EXECUTE pour exécuter la
fonction.
|
pg_ls_replslotdir ( slot_name text )
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification de
chaque fichier ordinaire dans le répertoire
pg_replslot/slot_name . Les fichiers dont le nom
commence avec un point, les répertoires et les autres fichiers spéciaux
sont exclus.
Cette fonction est restreinte aux superutilisateurs et aux rôles ayant les
droits du rôle pg_monitor par défaut, mais les autres
utilisateurs peuvent se voir donner le droit EXECUTE pour exécuter la
fonction.
|
pg_ls_archive_statusdir ()
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification
de chaque fichier ordinaire dans le répertoire des statuts d'archivage.
Les fichiers dont le nom commence avec un point, les répertoires et
les autres fichiers spéciaux sont exclus.
Cette fonction est restreinte par défaut aux superutilisateurs et aux
utilisateurs membres du rôle pg_monitor , mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
|
pg_ls_tmpdir ( [ tablespace oid ] )
→ setof record
( name text ,
size bigint ,
modification timestamp with time zone )
Renvoie le nom, la taille et l'horodatage de la dernière modification
de chaque fichier ordinaire dans le répertoire des fichiers
temporaires pour le tablespace indiqué. Si
tablespace est omis, le tablespace
pg_default est examiné. Les fichiers dont le nom
commence avec un point, les répertoires et les autres fichiers
spéciaux sont exclus.
Cette fonction est restreinte par défaut aux superutilisateurs et aux
utilisateurs membres du rôle pg_monitor , mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
|
pg_read_file ( filename text [, offset bigint , length bigint ] [, missing_ok boolean ] )
→ text
Renvoie tout ou partie d'un fichier texte, en commençant à l'octet
indiqué par offset , en renvoyant au plus
length octets (moins si la fin du fichier est
atteinte avant). Si offset est négatif, il est
relatif à la fin du fichier. Si offset et
length sont omis, le fichier entier est
renvoyé. Les octets lus dans le fichier sont interprétés comme une
chaîne dans l'encodage de la base ; une erreur est renvoyée s'ils
ne sont pas valides pour cet encodage.
Cette fonction est restreinte par défaut aux superutilisateurs, mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
|
pg_read_binary_file ( filename text [, offset bigint , length bigint ] [, missing_ok boolean ] )
→ bytea
Renvoie tout ou partie d'un fichier. Cette fonction est identique à
pg_read_file sauf qu'elle peut lire toute donnée
binaire, en renvoyant le résultat sous la forme d'un
bytea , et non pas d'un text ; de ce
fait, aucune vérification d'encodage n'est réalisée.
Cette fonction est restreinte par défaut aux superutilisateurs, mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
En combinant avec la fonction convert_from , cette
fonction peut être utilisée pour lire un fichier texte dans un
encodage spécial et le convertir dans l'encodage de la base :
SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
|
pg_stat_file ( filename text [, missing_ok boolean ] )
→ record
( size bigint ,
access timestamp with time zone ,
modification timestamp with time zone ,
change timestamp with time zone ,
creation timestamp with time zone ,
isdir boolean )
Renvoie un enregistement contenant la taille du fichier, son
horodatage de dernier accès, celui de dernière modification, celui de
dernier changement de statut (plateformes Unix uniquement),
l'horodatage de création (Windows uniquement), et un drapeau indiquant
si c'est un répertoire.
Cette fonction est restreinte par défaut aux superutilisateurs, mais
d'autres utilisateurs peuvent se voir donner le droit EXECUTE pour
cette fonction.
|
9.28.10. Fonctions sur les verrous consultatifs #
Les fonctions listées dans Tableau 9.106 gèrent les verrous
consultatifs. Pour les détails sur une utilisation correcte de ces
fonctions, voir Section 13.3.5.
Toutes ces fonctions ont pour but d'être utilisées pour verrouiller des
ressources définies par l'application, qui peuvent être identifiées soit
par une valeur de clé sur 64 bits, soit par deux valeurs de clés sur 32
bits (notez que ces deux espaces de clés ne se surchargente pas). Si une
autre session détient déjà un verrou conflictuel sur le même identifiant
de ressource, les fonctions devront soit attendre que la ressource
devienne disponible, soit renvoyer un résultat false
,
comme approprié pour la fonction. Les verrous peuvent être soit partagés
soit exclusifs ; un verrou partagé n'entre pas en conflit avec
d'autres verrous partagés sur la même ressource, mais entre en conflit
avec les verrous exclusifs. Les verrous peuvent se prendre au niveau de la
session (pour qu'ils soient détenus jusqu'à leur suppression ou jusqu'à la
fin de la session) ou au niveau de la transaction (pour qu'ils soient
détenus jusqu'à la fin de la transaction ; il n'existe pas de moyen
pour les supprimer manuellement). Les demandes multiples de verrou au
niveau session s'empilent, pour que, si le même identifiant de ressource
est verrouillé trois fois, alors il doit y avoir trois demandes de
déverrouillage pour relâcher la ressource avant que la session se termine.
Tableau 9.106. Fonctions pour les verrous informatifs
Fonction
Description
|
---|
pg_advisory_lock ( key bigint )
→ void
pg_advisory_lock ( key1 integer , key2 integer )
→ void
Obtient un verrou informatif exclusif niveau session, en attendant si nécessaire.
|
pg_advisory_lock_shared ( key bigint )
→ void
pg_advisory_lock_shared ( key1 integer , key2 integer )
→ void
Obtient un verrou informatif partagé niveau session, en attendant si nécessaire.
|
pg_advisory_unlock ( key bigint )
→ boolean
pg_advisory_unlock ( key1 integer , key2 integer )
→ boolean
Relâche un verrou informatif exclusif niveau session précédemment
acquis. Renvoie true si le verrou a été relâché
avec succès. Si le verrou n'était pas détenu, false
est renvoyé et, en plus, un message d'avertissement SQL est reporté au
serveur.
|
pg_advisory_unlock_all ()
→ void
Relâche tous les verrous informatifs niveau session détenus par la
session en cours. (Cette fonction est appelée implicitement à la fin
d'une session, même si le client s'est mal déconnecté.)
|
pg_advisory_unlock_shared ( key bigint )
→ boolean
pg_advisory_unlock_shared ( key1 integer , key2 integer )
→ boolean
Relâche un verrou informatif partagé niveau session précédemment
acquis. Renvoie true si le verrou a été relâché
avec succès. Si le verrou n'était pas détenu, false
est renvoyé et, en plus, un message d'avertissement SQL est reporté au
serveur.
|
pg_advisory_xact_lock ( key bigint )
→ void
pg_advisory_xact_lock ( key1 integer , key2 integer )
→ void
Obtient un verrou informatif exclusif niveau transaction, en attendant
si nécessaire.
|
pg_advisory_xact_lock_shared ( key bigint )
→ void
pg_advisory_xact_lock_shared ( key1 integer , key2 integer )
→ void
Obtient un verrou informatif partagé niveau transaction, en attendant
si nécessaire.
|
pg_try_advisory_lock ( key bigint )
→ boolean
pg_try_advisory_lock ( key1 integer , key2 integer )
→ boolean
Obtient un verrou informatif exclusif niveau session si disponible.
Cela va soit obtenir immédiatement le verrou et renvoyer
true , soit renvoyer false sans
attendre si le verrou ne peut pas être acquis immédiatement.
|
pg_try_advisory_lock_shared ( key bigint )
→ boolean
pg_try_advisory_lock_shared ( key1 integer , key2 integer )
→ boolean
Obtient un verrou informatif partagé niveau session si disponible.
Cela va soit obtenir immédiatement le verrou et renvoyer
true , soit renvoyer false sans
attendre si le verrou ne peut pas être acquis immédiatement.
|
pg_try_advisory_xact_lock ( key bigint )
→ boolean
pg_try_advisory_xact_lock ( key1 integer , key2 integer )
→ boolean
Obtient un verrou informatif exclusif niveau transaction si disponible.
Cela va soit obtenir immédiatement le verrou et renvoyer
true , soit renvoyer false sans
attendre si le verrou ne peut pas être acquis immédiatement.
|
pg_try_advisory_xact_lock_shared ( key bigint )
→ boolean
pg_try_advisory_xact_lock_shared ( key1 integer , key2 integer )
→ boolean
Obtient un verrou informatif partagé niveau transaction si disponible.
Cela va soit obtenir immédiatement le verrou et renvoyer
true , soit renvoyer false sans
attendre si le verrou ne peut pas être acquis immédiatement.
|