Cette section décrit le format de stockage au niveau des fichiers et répertoires.
Traditionnellement, les fichiers de configuration et les fichiers de données utilisés
par une instance du serveur sont stockés ensemble dans le répertoire des données,
habituellement référencé en tant que PGDATA
(d'après le nom de
la variable d'environnement qui peut être utilisé pour le définir). Un emplacement
courant pour PGDATA
est /var/lib/pgsql/data
.
Plusieurs groupes, gérés par différentes instances du serveur, peuvent exister sur
la même machine.
Le répertoire PGDATA
contient plusieurs sous-répertoires et
fichiers de contrôle, comme indiqué dans le Tableau 69.1.
En plus de ces éléments requis, les fichiers
de configuration du groupe, postgresql.conf
,
pg_hba.conf
et pg_ident.conf
sont
traditionnellement stockés dans PGDATA
(bien qu'il soit possible de
les placer ailleurs).
Tableau 69.1. Contenu de PGDATA
Élément | Description |
---|---|
PG_VERSION | Un fichier contenant le numéro de version majeur de PostgreSQL |
base | Sous-répertoire contenant les sous-répertoires par base de données |
current_logfiles | Fichier contenant le ou les fichiers de trace en cours d'écriture par le gestionnaire de traces. |
global | Sous-répertoire contenant les tables communes au groupe, telles que
pg_database |
pg_commit_ts | Sous-répertoire contenant des données d'horodatage des validations de transations |
pg_dynshmem | Sous-répertoire contenant les fichiers utilisés par le système de gestion de la mémoire partagée dynamique |
pg_logical | Sous-répertoire contenant les données de statut pour le décodage logique |
pg_multixact | Sous-répertoire contenant des données sur l'état des multi-transactions (utilisé pour les verrous de lignes partagées) |
pg_notify | Sous-répertoire contenant les données de statut de LISTEN/NOTIFY |
pg_replslot | Sous-répertoire contenant les données des slots de réplication |
pg_serial | Sous-répertoire contenant des informations sur les transactions sérialisables validées |
pg_snapshots | Sous-répertoire contenant les snapshots (images) exportés |
pg_stat | Sous-répertoire contenant les fichiers permanents pour le sous-système de statistiques |
pg_stat_tmp | Sous-répertoire contenant les fichiers temporaires pour le sous-système des statistiques |
pg_subtrans | Sous-répertoire contenant les données d'états des sous-transaction |
pg_tblspc | Sous-répertoire contenant les liens symboliques vers les espaces logiques |
pg_twophase | Sous-répertoire contenant les fichiers d'état pour les transactions préparées |
pg_wal | Sous-répertoire contenant les fichiers WAL (Write Ahead Log) |
pg_xact | Sous-répertoire contenant les données d'état de validation des transactions |
postgresql.auto.conf | Fichier utilisé pour les paramètres configurés avec la commande
ALTER SYSTEM |
postmaster.opts | Un fichier enregistrant les options en ligne de commande avec lesquelles le serveur a été lancé la dernière fois |
postmaster.pid | Un fichier verrou contenant l'identifiant du processus postmaster en
cours d'exécution (PID), le chemin du répertoire de données, la date et
l'heure du lancement de postmaster, le numéro de port, le chemin du
répertoire du socket de domaine Unix (vide sous Windows), la première adresse
valide dans listen_address (adresse IP ou * , ou vide s'il
n'y a pas d'écoute TCP) et l'identifiant du segment de mémoire partagé (ce
fichier est supprimé à l'arrêt du serveur) |
Pour chaque base de données dans le groupe, il existe un sous-répertoire dans
PGDATA
/base
, nommé d'après l'OID de la base de données
dans pg_database
. Ce sous-répertoire est l'emplacement par
défaut pour les fichiers de la base de données; en particulier, ses
catalogues système sont stockés ici.
Chaque table et index est stocké dans un fichier séparé. Pour les relations
ordinaires, ces fichiers sont nommés d'après le numéro
filenode de la table ou de l'index. Ce numéro est stocké
dans pg_class
.relfilenode
.
Pour les relations temporaires, le nom du fichier est de la forme
t
,
où BBB
_FFF
BBB
est l'identifiant du processus serveur qui a
créé le fichier, et FFF
et le numéro
filenode. Dans tous les cas, en plus du fichier principal
(aussi appelé main fork), chaque table et index
a une carte des espaces libres (voir Section 69.3), qui enregistre des informations sur l'espace libre
disponible dans la relation. La carte des espaces libres est stockée dans un
fichier dont le nom est le numéro filenode suivi du suffixe
_fsm
. Les tables ont aussi une carte des
visibilités, stockée dans un fichier de suffixe
_vm
, pour tracer les pages connues comme n'ayant pas de
lignes mortes. La carte des visibilités est décrite dans Section 69.4. Les tables non tracées et les index disposent d'un
troisième fichier, connu sous le nom de fichier d'initialisation. Son nom a
pour suffixe _init
(voir Section 69.5).
Notez que, bien que le filenode de la table correspond souvent à son OID,
cela n'est pas nécessairement le cas; certaines
opérations, comme TRUNCATE
, REINDEX
,
CLUSTER
et quelques formes d'ALTER TABLE
, peuvent
modifier le filenode tout en préservant l'OID. Évitez de supposer que filenode
et OID sont identiques.
De plus, pour certains catalogues système incluant
pg_class
lui-même,
pg_class
.relfilenode
contient zéro. Le numéro filenode en cours est stocké dans une structure de
données de bas niveau, et peut être obtenu avec la fonction
pg_relation_filenode()
.
Quand une table ou un index dépasse 1 Go, il est divisé en
segments d'un Go. Le nom du fichier du premier
segment est identique au filenode ; les segments suivants sont nommés
filenode.1, filenode.2, etc. Cette disposition évite des problèmes sur les
plateformes qui ont des limitations sur les tailles des fichiers.
(Actuellement, 1 Go est la taille du segment par défaut. Cette taille est
ajustable en utilisant l'option --with-segsize
pour configure
avant de construire PostgreSQL.)
En principe, les fichiers de la carte des espaces libres et de la carte de
visibilité pourraient aussi nécessiter plusieurs segments, bien qu'il y ait
peu de chance que cela arrive réellement.
Une table contenant des colonnes avec des entrées potentiellement volumineuses
aura une table TOAST associée, qui est
utilisée pour le stockage de valeurs de champs trop importantes pour
conserver des lignes adéquates.
pg_class
.reltoastrelid
établit un lien entre
une table et sa table TOAST, si elle existe. Voir Section 69.2 pour plus d'informations.
Le contenu des tables et des index est discuté plus en détails dans Section 69.6.
Les tablespaces rendent ce scénario plus compliqué. Chaque espace
logique défini par l'utilisateur contient un lien symbolique dans le répertoire
PGDATA
/pg_tblspc
, pointant vers le répertoire physique
du tablespace (celui spécifié dans la commande CREATE
TABLESPACE
). Ce lien symbolique est nommé d'après l'OID du tablespace.
À l'intérieur du répertoire du tablespace, il existe un sous-répertoire
avec un nom qui dépend de la version du serveur PostgreSQL,
comme par exemple PG_9.0_201008051
. (La raison de l'utilisation
de ce sous-répertoire est que des versions successives de la base de données
puissent utiliser le même emplacement indiqué par CREATE
TABLESPACE
sans que cela provoque des conflits.) À l'intérieur de
ce répertoire spécifique à la version, il existe un sous-répertoire
pour chacune des bases de données contenant des éléments dans ce tablespace. Ce
sous-répertoire est nommé d'après l'OID de la base. Les tables et les index
sont enregistrés dans ce répertoire et suivent le schéma de nommage des filenodes. Le tablespace
pg_default
n'est pas accédé via pg_tblspc
mais
correspond à PGDATA
/base
. De façon similaire,
le tablespace pg_global
n'est pas accédé via
pg_tblspc
mais correspond à PGDATA
/global
.
La fonction pg_relation_filepath()
affiche le chemin
entier (relatif à PGDATA
) de toute relation. Il est souvent
utile pour ne pas avoir à se rappeler toutes les différentes règles ci-dessus.
Gardez néanmoins en tête que cette fonction donne seulement le nom du premier
segment du fichier principal de la relation -- vous pourriez avoir
besoin d'ajouter le numéro de segment et/ou les extensions
_fsm
, _vm
ou _init
pour trouver tous les
fichiers associés avec la relation.
Les fichiers temporaires (pour des opérations comme le tri de plus de données
que ce que la mémoire peut contenir) sont créés à l'intérieur de PGDATA
/base/pgsql_tmp
,
ou dans un sous-répertoire pgsql_tmp
du répertoire du
tablespace si un tablespace autre que pg_default
est
indiqué pour eux. Le nom du fichier temporaire est de la forme
pgsql_tmp
,
où PPP
.NNN
PPP
est le PID du serveur propriétaire et
NNN
distingue les différents fichiers temporaires de ce
serveur.