Atomicité, Cohérence, Isolation et Durabilité. Cet ensemble de propriétés des transactions de base de données permet de garantir la validité lors des opérations concurrentes et même en cas d'événements d'erreurs, coupures de courant, ...

Le processus de collecter des statistiques des données en tables et autres relations pour aider le planificateur de requêtes à prendre les bonnes décisions sur l'exécution des requêtes.

(Ne confondez pas ce terme avec l'option ANALYZE de la commande EXPLAIN.)

Pour plus d'informations, voir ANALYZE.

La propriété d'une transaction qui assure que toutes ses opérations se terminent comme une seule unité au complet ou pas du tout. De plus, si une panne système se produit lors de l'exécution d'une transaction, aucun résultat partiel n'est visible après la restauration. C'est une des propriétés ACID.

En référence à une donnée : Le fait que sa valeur ne peut pas être divisée en plus petits composants.

En référence à une transaction de base de données : voir atomicité.

Un élément avec un certain nom et un certain type de données trouvé dans une ligne.

Un ensemble de processus en tâche de fond qui effectuent régulièrement les opérations vacuum et analyze. Le processus auxiliaire qui coordonne le travail est est toujours présent (sauf si autovacuum est désactivé) est connu sous le nom de autovacuum launcher, et les processus qui font le boulot sont appelés autovacuum workers.

Pour plus d'informations, voir Section 25.1.6.

Un processus à l'intérieur d'une instance en charge d'une tâche de fond spécifique pour l'instance. Voici quelques processus auxiliaire le autovacuum launcher (mais pas les workersworkers), le background writer, le checkpointer, le logger, le startup process, le WAL archiver, le WAL receiver (mais par les WAL senders), et le WAL writer.

Processus d'une instance agissant au nom du client et gérant ses requêtes.

Ne confondez pas ce terme avec les termes similaires Background Worker ou Background Writer.

Processus dans l'instance, qui exécute le système - ou le code fourni par les utilisateurs. Sert comme infrastructure pour de nombreuses fonctionnalités dans PostgreSQL, telles que la réplication logique et les requêtes parallélisées. De plus, les extensions peuvent ajouter des processus background workers personnalisés.

Pour plus d'informations, voir Chapitre 48.

Un processus auxiliaire qui écrit les blocs de données modifiés sur le système de fichiers. Il se réveille périodiquement mais ne fonctionne que sur une courte période de temps dans le but de distribuer sa coûteuse activité I/O dans le temps pour éviter de larges pics d'I/O qui peuvent bloquer les autres processus.

Pour plus d'informations, voir Section 20.4.5.

Une collection nommée d' objets SQL locaux.

Pour plus d'informations, voir Section 23.1.

La structure basique utilisée pour stocker des données de relation. Tous les blocs ont la même taille. Les blocs de données sont typiquement stockés sur disque, chacun dans un fichier spécifique, et peuvent être lus dans le tampon de mémoire partagée où ils peuvent être modifiés, devenant sales (dirty en anglais). Elles deviennent propres quand elles sont écrites sur le disque. Les nouvelles pages, qui initialement existent en mémoire seulement, sont aussi sales jusqu'à leur écriture.

Une structure de stockage qui garde les méta-données sur chaque bloc de données du fork principal d'une table. Les entrées de la carte des espaces libres pour chaque bloc stocke la quantité d'espace libre disponibles pour les futurs enregistrements, et est structurée pour être rendre performante la recherche d'espace libre pour les nouveaux enregistrements d'une taille donnée.

Pour plus d'informations, voir Section 73.3.

Une structure sur disque qui conserve des métadonnées sur chaque bloc de données d'une table. Un enregistrement de la carte de visibilité pour chaque bloc enregistre deux bits : le premier (tous-visibles) indique que tous les enregistrements de ce blocs sont visibles par toutes les transactions. Le second (tous-gelés) indique que toutes les lignes du bloc sont marquées comme étant gelées.

Le standard SQL utilise ce terme pour indiquer ce qui est appelé une base de données dans la terminologie PostgreSQL.

(Ne confondez pas ce terme avec les catalogues systèmes).

Pour plus d'informations, voir Section 23.1.

Pour cette documentation, synonyme de super-utilisateur ou administrateur de la base de données.

Une collection de tables décrivant la structure de tous les objets SQL de l'instance. Le catalogue système réside dans le schéma pg_catalog. Ces tables contiennes les données dans une représentation interne et ne sont pas typiquement considérées utiles pour l'utilisateur ; un nombre de vues plus compréhensibles, présentes aussi dans le schéma pg_catalog, offrent un accès plus agréable à certaines de ces informations, alors que des tables et vues supplémentaires existent dans le schéma information_schema (voir Chapitre 37) pour exposer certaines des mêmes informations comme demandé par le standard SQL.

Pour plus d'informations, voir Section 5.9.

Un point dans la séquence WAL à partir de laquelle il est garanti que les fichiers de données des relations ont été mis à jour avec toutes les informations depuis la mémoire partagée modifiées avant ce checkpoint ; un enregistrement checkpoint est écrit et déversé dans le WAL pour marquer ce point.

Un checkpoint est aussi le fait d'amener à bien toutes les actions qui sont nécessaires pour arriver au checkpoint comme décrit ci-dessus. Ce processus est initié quand des conditions prédéfinies sont rencontrées, comme quand un interval de temps défini est passé, ou parce qu'un certain volume d'enregistrements ont été écrits ; il peut aussi être invoqué manuellement par l'utilisateur avec la commande CHECKPOINT.

Pour plus d'informations, voir Section 30.5.

Un processus auxiliaire spécialisé responsable de l'exécution des checkpoints.

Un moyen d'identifier un enregistrement dans une table ou une autre relation par valeur contenues dans un ou plusieurs attributs de cette relation.

Un type de contrainte définie sur une ou plusieurs colonnes dans une table qui requiert la ou les valeur(s) dans ces colonnes pour identifier zéro ou un enregistrement dans une autre (ou, moins fréquemment, la même) table.

Un cas particulier de contrainte d'unicité défini sur une table ou une autre relation qui garantit en plus que tous les attributs formant la clé primaire n'ont pas de valeurs NULL. Comme le nom l'indique, il ne peut y avoir qu'une seule clé primaire par table, bien qu'il soit possible d'avoir plusieurs contraintes d'unicité qui ont aussi des attributs non NULL.

N'importe quel processus, potentiellement distant, qui établit une session en se connectant à une instance pour interagir avec une base de données.

La propriété que les données dans la base de données sont toujours conformes avec les contraintes d'intégrité. Des transactions peuvent être autorisées à enfreindre certaines contraintes temporairement avant qu'elle soit validée par un COMMIT, mais si ces infractions ne sont toujours pas résolues au moment de la validation, alors une telle transaction est automatiquement annulée (ROLLBACK). Ceci est une des propriétés ACID.

L'utilisateur du système d'exploitation qui est le propriétaire du répertoire de données et sous lequel le processus postgres est exécuté. Il est nécessaire que cet utilisateur existe avant de créer une nouvelle instance de bases de données.

Sur les systèmes d'exploitation possédant un utilisateur root, cet utilisateur ne peut pas être le propriétaire de l'instance.

Un attribut trouvé dans une table ou une vue.

L'acte de finaliser une transaction dans la base de données, qui rend ses modifications visible aux autres transactions et assure leur durabilité.

Pour plus d'informations, voir COMMIT.

Le concept de multiples opérations indépendantes se réalisant dans la base de données en même temps. Dans PostgreSQL, la concurrence est contrôlée par le mécanisme de contrôle de concurrence multiversion.

Une ligne de communication établie entre un processus client et un processus backend, habituellement à travers le réseau, supportant une session. Ce terme est parfois utilisé comme synonyme de session.

Pour plus d'informations, voir Section 20.3.

Une restriction sur les valeurs des données autorisées dans une table, ou sur les attributs d'un domain.

Pour plus d'informations, voir Section 5.4.

Un type de contrainte défini sur une relation qui restreint les valeurs autorisées dans un ou plusieurs attributs. La contrainte de validation peut faire référence à n'importe quel attribut du même enregistrement dans la relation, mais ne peut pas référencer d'autres enregistrements de la même relation ou d'autres relations.

Pour plus d'informations, voir Section 5.4.

Un type de contrainte définie sur une relation qui restreint les valeurs autorisées dans une colonne ou une combinaison de colonnes, pour que chaque valeur ou combinaison de valeurs puisse apparaître seulement une fois dans la relation -- c'est-à-dire qu'il n'existe aucune autre ligne dans la relation contenant des valeurs égales à cette ligne.

Comme les valeurs NULL ne sont pas considérées égales entre elles, plusieurs lignes peuvent avoir des valeurs NULL sans violer la contrainte d'unicité.

Une commande SQL utilisée pour ajouter, modifier ou supprimer sous condition des lignes dans une table donnée, en utilisant les données d'une relation source.

Pour plus d'informations, voir MERGE.

Un mécanisme désigné pour permettre à plusieurs transactions de lire et écrire les mêmes enregistrements sans qu'un processus fasse attendre les autres processus. Dans PostgreSQL, le MVCC est implémenté par création de copies (versions) des lignes dès qu'elles sont modifiées ; une fois que toutes les transactions qui voient les vieilles versions sont terminées, ces vieilles versions peuvent être supprimées.

Le premier utilisateur initialisé dans une instance de base de données.

Cet utilisateur est le propriétaire de tous les catalogues systèmes dans chaque base de données. C'est aussi le rôle à l'origine de tous les droits donnés. De ceci découle le fait que ce rôle ne peut pas être supprimé.

Ce rôle se comporte aussi comme un superutilisateur standard.

Certaines opérations auront accès à un grand nombre de blocs. Une stratégie d'accès aux buffers aide à empêcher que ces opérations évincent trop de blocs du cache disque de PostgreSQL (les shared buffers).

Une stratégie d'accès aux buffers configure des références à un nombre limité de blocs en cache et les ré-utilise cycliquement. Quand l'opération a besoin d'un nouveau bloc, un buffer victime est choisi parmi les buffers de la stratégie, ce qui peut nécessiter d'écrire les données modifiées du bloc sur disque et potentiellement aussi de placer les WAL sur un stockage permanent.

Les stratégies d'accès aux buffers sont utilisées pour différentes opérations comme les parcours séquentielles des tables volumineuses, VACUUM, COPY, CREATE TABLE AS SELECT, ALTER TABLE, CREATE DATABASE, CREATE INDEX et CLUSTER.

Une conversion d'une donnée depuis son type actuel vers un autre type.

Pour plus d'informations, voir CREATE CAST.

La traduction de l'utilisateur local à la base en un utilisateur sur le système distant défini par un wrapper de données distantes.

For more information, see CREATE USER MAPPING.

Une commande SQL qui supprime des enregistrements d'une table donnée ou d'une relation.

Pour plus d'informations, voir DELETE.

Un type de données défini par l'utilisateur qui est basé sur un autre type de données sous-jacent. Il agit de la même façon que le type sous-jacent sauf pour le restriction potentielle de l'ensemble de valeurs autorisées.

Pour plus d'informations, voir² Section 8.18.

La représentation interne d'une valeur dans un type de données SQL.

L'assurance qu'une fois qu'une transaction a été validée par un ordre COMMIT, la modification est conservée même après une erreur système ou un arrêt brutal. C'est l'une des propriétés ACID.

Une collection d'attributs dans un ordre fixe. Cet ordre peut être défini par la table (ou une autre relation relation) où l'enregistrement est contenu, auquel cas l'enregistrement est souvent appelé une tuple en anglais. Il pourrait aussi être défini par la structure d'un ensemble de résultats, auquel case il est souvent appelé record en anglais. En français, et particulièrement pour cette traduction, le terme habituellement utilisé est ligne.

Terme archaique pour un enregistrement WAL.

Une description bas niveau d'un changement de données individuel. Il contient suffisamment d'informations sur le changement de données pour être ré-exécuté (re-joué) en cas d'un problème système qui aurait causer la perte de ce changement. Les enregistrements WAL utilisent un format binaire non affichable.

Pour plus d'informations, voir Section 30.6.

Une variante d'un checkpoint réalisé sur un replica.

Pour plus d'informations, voir Section 30.5.

Une relation transmise à partir d'un processus serveur vers un client suite à l'exécution réussie d'une commande SQL, habituellement un SELECT mais cela pourrait aussi être une commande INSERT, UPDATE ou DELETE si la clause RETURNING est spécifiée.

Le fait qu'un ensemble de résultats est une relation signifie qu'une requête peut être utilisée dans la définition d'une autre requête, devenant ainsi une sous-requête.

Un module complémentaire qui peut être installé sur une instance pour fournir des fonctionnalités supplémentaires.

Pour plus d'informations, voir Section 38.17.

Les fichiers journaux contiennent des lignes de texte sous forme lisible par un être humain sur les événements produits. Les exemples incluent les échecs de connexion, les requêtes longues, etc.

Pour plus d'informations, voir Section 25.3.

Aussi connu sous le nom de segment WAL ou de fichier segment WAL. Chacun des fichiers numérotés séquentiellement qui fournissent de l'espace de stockage pour les WAL. Les fichiers sont tous de la même taille prédéfinie et sont écrits dans l'ordre séquentiel, are all of the same predefined size and are written in sequential order, entrecroisant les changements quand ils surviennent dans plusieurs sessions simultanées. Si le système s'arrête brutalement, les fichiers sont lus dans l'ordre et chacun des changements est rejoué pour restaurer le système dans l'état qu'il avait avant le crash.

Chaque fichier WAL peut être relâcher une fois qu'un checkpoint a écrit toutes les modifications que le fichier contenait dans les fichiers de données correspondant. Relâcher un fichier se fait soit en le supprimant soit en modifiant son nom pour qu'il soit réutilisé dans le futur, ce qui est appelé recycler.

Pour plus d'informations, voir Section 30.6.

Un type de routine qui recoit zéro ou plusieurs arguments, retourne zéro ou plusieurs valeurs, et sont contraintes de s'exécuter dans une transaction. Les fonctions sont invoquées comme une partie de la requête, par exemple via SELECT. Certaines fonctions peuvent retourner des ensembles, elles sont appelées fonctions à retour d'ensemble.

Les fonctions peuvent être utilisées par les triggers.

Pour plus d'informations, voir CREATE FUNCTION.

Une fonction qui combine (agrège) de multiples valeurs en entrée, pour, par exemple, les compter, faire une moyenne ou une somme, produisant ainsi une seule valeur en sortie.

Pour plus d'informations, voir Section 9.21.

Voir aussi Fonctions (routine) de fenêtrage (Window Function).

Un genre de function utilisé dans une requête qui s'applique à une partition de l'ensemble de résultat de la requête ; le résultat de la fonction est basé sur les valeurs trouvées dans les lignes de la même partition ou cadre.

Toutes les fonctions d'agrégat peuvent être utilisées comme fonctions de fenêtrage, mais les fonctions de fenêtrage peuvent aussi être utilisées pour donner des rangs à chaque ligne de la partition par exemple. Elles sont aussi connues sous le nom de fonctions analytiques.

Pour plus d'informations, voir Section 3.5.

Chacun des ensembles des fichiers séparés par segment dans lesquels une relation est stockée. Le fork principal (main fork) est le fichier où résident les données actuelles. Il existe aussi deux forks secondaires pour les métadonnées : la carte des espaces libres et la carte de visibilité. Les relations non journalisées ont aussi un fork initial.

Une copie binaire de tous les fichiers de l'instance. Elle est générée par l'outil pg_basebackup. Avec les fichiers WAL, elle peut être utilisée comme point de départ pour une restauration et pour une réplication en log shipping(envoi des journaux entiers) ou en streaming(flux).

L'espace dans les pages de données qui ne contient pas de versions vivantes des enregistrements, donc un espace inutilisé (libre).

Une commande SQL qui est utilisée pour permettre à un utilisateur ou à un rôle d'accéder à des objets spécifiques dans la base de données.

Pour plus d'informations, voir GRANT.

Contient les valeurs des attributs des enregistrements (i.e. les données) pour une relation. La partie heap est structurée par un ou plusieurs fichiers segments dans le fork principal de la relation.

Un ordinateur qui communique avec d'autres ordinateurs à travers un réseau. Ce terme est souvent synonyme de serveur. Il est aussi utilisé pour désigner l'ordinateur quand les processus client s'exécutent.

L'identifiant numérique, unique, affecté en séquence que chaque transaction reçoit quand elle réalise sa première modification en base. Son abréviation fréquente est xid. Lorsqu'elle est stockée sur disque, les XID ont 32 bits, donc seuls approximativement 4 milliards d'identifiants de transaction en écriture peuvent être générés ; pour permettre au système de fonctionner plus longtemps que cela, les epochs sont utilisés, là-aussi sur 32 bits. Quand le compteur arrive à la valeur maximale d'un XID, il recommence à la valeur 3 (les valeurs inférieures sont réservées) et la valeur epoch est incrémentée de 1. Dans certains contextes, les valeurs epoch et XID sont considérées ensemble comme une seule valeur de 64 bits ; voir Section 74.1 pour plus de détails.

Pour plus d'informations, voir Section 8.19.

Une relation qui contient des données dérivées d'une table ou d'une vue matérialisée. Sa structure interne permet une récupération rapide et un accès aux données originelles.

Pour plus d'informations, voir CREATE INDEX.

Une commande SQL utilisée pour ajouter de nouvelles données dans une table.

Pour plus d'informations, voir INSERT.

Un groupe de processus backend et processus auxiliaire qui communiquent en utilisant une zone de mémoire partagée commune. Un processus postmaster gère l'instance ; une instance gère exactement toutes ses bases de données. Plusieurs instances peuvent s'exécuter sur le même serveur aussi longtemps que leur ports TCP n'entrent pas en conflit.

L'instance supporte toutes les fonctionnalités clés d'un SGBD : accès en lecture et écriture aux fichiers et mémoire partagée, respect des propriétés ACID, connexions aux processus client, vérification des droits, restauration après panne, réplication, etc.

Une collection de bases de données et d'objets SQL globaux, et leurs méta-données statiques et dynamiques communes. Parfois désigné sous le terme de cluster. Une instance de base de données est créée en utilisant le programme initdb.

Dans PostgreSQL, le terme cluster est aussi parfois utilisé pour désigner une instance. (Ne confondez pas ce terme avec la commande SQL CLUSTER.)

Voir aussi propriétaire de l'instance, un utilisateur du système d'exploitation, et superutilisateur original, le propriétaire PostgreSQL d'une instance.

Une façon de restreindre les données dans une relation par une clé étrangère pour qu'il y ait uniquement des données correspondantes dans une autre relation.

La propriété que les effets d'une transaction ne sont pas visibles par les transactions concurrentes avant qu'elle ne soit validée par un COMMIT. C'est une des propriétés ACID.

Pour plus d'informations, voir Section 13.2.

Une opération et un mot clé SQL (ce dernier pour le mot anglais évidemment) utilisés dans les requêtes pour combiner les données de multiples relations.

Le journal qui conserve la trace des changements dans l'instance du serveur lorsque des opérations utilisateur et système surviennent. Il comprend de nombreux enregistrements WAL écrits séquentiellement dans les fichiers WAL.

Une table est considérée comme journalisée si ces changements sont envoyés dans les journaux de transactions (WAL). Par défaut, toutes les tables régulières sont journalisées. Une table peut être spécifiée comme non journalisée soit à sa création ou via la commande ALTER TABLE.

Un processus auxiliaire Si activé, le processus Logger écrit des informations sur les événements de base de données dans le fichier journal courant. Au bout d'un certain temps ou après un certain volume, un nouveau fichier journal est créé. Aussi appelé syslogger.

Pour plus d'informations, voir Section 20.8.

Décalage d'octets dans les WAL, augmentant de façon monotone à chaque nouvel enregistrement WAL.

Pour plus d'informations, voir pg_lsn et Section 30.6.

La propriété que certaines informations ont été pré-calculées et stockées pour un usage ultérieur, plutôt que calculées à la volée.

Ce terme est utilisé dans les vues matérialisées, pour signifier que les données dérivées depuis la requête de la vue sont stockées sur disque séparément de la source de ces données.

Le terme peut aussi référer à des requêtes multi-étapes pour signifier que les données résultantes de l'exécution d'une étape donnée sont stockées en mémoire (avec possibilité d'être déversées sur le disque), et ainsi peuvent être lues plusieurs fois par une autre étape.

RAM utilisé par les processus d'une même instance. Il contient des parties des fichiers de la base, fournit un espace temporaire pour les enregistrements WAL et stocke des informations communes supplémentaires. Notez que la mémoire partagée appartient à l'instance complète, pas à une seule base de données.

La partie la plus importante de la mémoire partagée est connue sous le nom anglais de shared buffers et est utilisé pour être le miroir des fichiers de données, organisés en blocs. Quand un bloc est modifié, il est appelé dirty jusqu'à ce qu'il soit écrit sur le système de fichiers.

Pour plus d'informations, voir Section 20.4.1.

La propriété de certaines relations précisant que leur modification ne doit pas être reflété dans les WAL. Ceci désactive la réplication et la restauration en cas de crash pour ces relations.

L'intérêt principal des tables non journalisées est d'enregistrer des données temporaires de travail pouvant être partagées entre plusieurs processus.

Les tables temporaires sont toujours non journalisées.

Un concept de non-existence qui est un principe central dans la théorie des bases de données relationnelles. Il représente l'absence d'une valeur définie.

Tout objet créé avec une commande CREATE. La plupart des objets sont spécifiques à une base de données et sont communément appelés des objets locaux.

La plupart des objets locaux appartiennent à un schéma spécifique dans leur base, comme par exemple les relations (tous types), routines (tous types), les types de données, etc. Le nom des objets de même type dans le même schéma doit être unique.

Il existe aussi des objets locaux n'appartenant pas aux schémas ; pour exemple, les extensions, conversions de type de données et les wrappers de données distantes. Les noms des objets de même type doivent être uniques au sein de la même base de données.

Les autres types d'objets, tels que les rôles, tablespaces, origines de réplication, souscriptions pour la réplication logique et les bases elles-mêmes ne sont pas des objets locaux vu qu'ils existent en dehors d'une base spécifique ; ils sont appelés des objets globaux. Les noms de ces objets sont uniques au sein de l'instance.

Pour plus d'informations, voir Section 23.1.

Un ou plusieurs sous-ensembles disjoints (et non chevauchants) d'un plus large ensemble.

En référence aux tables partitionnées : une des tables qui contiennent chacune une partie des données de la table partitionnée, et qui est dite être le parent. La partition est elle-même une table, elle peut ainsi être requêtée directement ; en même temps, une partition peut parfois être une table partitionnée, permettant ainsi de créer des hiérarchies.

En référence aux fonctions de fenêtrage (window functions) dans une requête, une partition est un critère défini par l'utilisateur qui identifie les enregistrements voisins de l'ensemble de résultats d'une requête qui sont pris en compte par la fonction.

La partie de PostgreSQL qui est dédiée à la détermination (planification) de la façon la plus rapide pour exécuter des requêtes. Connu aussi sour le nom d'optimiseur de requêtes, optimiseur ou tout simplement planificateur.

Le tout premier processus d'une instance. Il démarre et gère les processus auxiliaires et crée les processus backend à la demande.

Pour plus d'informations, voir Section 19.3.

Quand deux ou plusieurs bases sont liées via la réplication, le serveur qui est considéré comme la source d'autorité des informations est appelé le primaire, aussi connu sous le nom de maître.

Un type de routine. Leurs qualités distinctives sont qu'elles ne renvoient pas de valeurs, et qu'elles sont autorisées à utiliser des instructions transactionnelles comme COMMIT et ROLLBACK. Elles sont appelées via la commande CALL.

Pour plus d'informations, voir CREATE PROCEDURE.

Le terme générique pour tous les objets dans une base qui ont un nom et une liste d'attributs définis dans un ordre spécifique. Les tables, séquences, vues, tables distantes, vues matérialisées, types composites et index sont tous des relations.

Plus globalement, une relation est un ensemble de lignes. Par exemple, le résultat d'une requête est aussi une relation.

Dans PostgreSQL, Class est un synonyme historique pour relation.

Un rôle ayant l'attribut SUPERUSER (voir Section 22.2).

Fréquemment appelé plus simplement un superutilisateur.

Le répertoire de base sur le système de fichiers d'un serveur qui contient tous les fichiers de données et sous-répertoires associés avec une instance (à l'exception des tablespaces et optionnellement de WAL). La variable d'environnement PGDATA est communément utilisée pour se référer au répertoire de données.

L'espace de stockage d'une instance comprend le répertoire de données ainsi que tous les tablespaces supplémentaires.

Pour plus d'informations, voir Section 73.1.

Une base qui est liée à une base primaire et qui maintient une copie de certaines ou toutes les données de la base primaire. Les raisons principales pour faire cela est de permettre un accès plus important aux données et pour maintenir la disponibilité des données dans le cas où le primaire devient indisponible.

Le fait de reproduire des données d'un serveur sur un autre serveur appelé réplicat. Cela peut prendre la forme d'une réplication physique, où toutes les modifications des fichiers d'un serveur sont copiées verbatim, ou la forme d'une réplication logique où un sous-ensemble défini de modifications de données est envoyé en utilisant une représentation de plus haut niveau.

Une requête envoyée par un client à un processus serveur, habituellement pour renvoyer des résultats ou pour modifier des données sur la base.

La possibilité de gérer des parties d'exécution d'une requête pour tirer profit des processus parallèles sur des serveurs avec multiples CPUs.

Une commande pour empêcher l'accès à un ensemble nommé d'objets de base pour une liste nommée de rôles.

Pour plus d'informations, voir REVOKE.

Une collection de droits d'accès à l'instance. Les rôles sont eux-même un droit qui peut être donné à d'autres rôles. Ceci est fait fréquemment pour simplifier la gestion des droits quand plusieurs users ont besoin des mêmes droits.

Pour plus d'informations, voir CREATE ROLE.

Une commande pour annuler toutes les opérations réalisées depuis le début d'une transaction.

Pour plus d'informations, voir ROLLBACK.

Un ensemble défini d'instructions enregistrées dans le système de bases de données, qui peut être appelé pour exécution. Une routine doit être écrite dans un des langages de programmation. Les routines peuvent être des fonctions (incluant les fonctions renvoyant des ensembles de lignes et les fonctions trigger), des fonctions d'agrégat, et des procédures.

Plusieurs routines sont déjà définies dans PostgreSQL mais des routines définies par les utilisateurs sont ajoutables.

Un marquage spécial dans une séquence d'étapes d'une transaction. Les modifications de données après ce point dans le temps peuvent être annulées jusqu'au moment du savepoint.

Pour plus d'informations, voir SAVEPOINT.

Un schéma est un espace de nom pour les objets SQL, qui appartiennent tous à la même base. Chaque objet SQL doit résider dans exactement un schéma.

Tous les objets SQL définis par le système résident dans le schéma pg_catalog.

Plus généralement, le terme schéma est utilisé pour signifier toutes les descriptions de données (définitions des tables, contraintes, commentaires, etc) pour une base donnée ou pour un sous-ensemble.

Pour plus d'informations, voir Section 5.9.

Un fichier physique qui stocke des données pour une relation donnée. Les segments de fichiers sont limités en taille par une valeur de configuration (typiquement 1 gigaoctet). Ainsi, si une relation excède cette taille, le fichier est séparée dans de multiples segments.

Pour plus d'informations, voir Section 73.1.

(Ne confondez pas ce terme avec le terme similaire de segment WAL).

La commande SQL utilisée pour réclamer des données d'une base. Normalement, les commandes SELECT ne modifient pas la base de données de quelque façon que ce soit. Cependant, il est possible que des fonctions appelées dans la requête aient comme effet de bord de modifier des données.

Pour plus d'informations, voir SELECT.

Un processus auxiliaire qui s'exécute sur un replica pour recevoir les en provenance d'un serveur primaire pour le rejeu par le startup process.

Pour plus d'informations, voir Section 27.2.

Un processus backend spécial qui envoie en flux les WAL sur un réseau. Le bout de réception peut être un WAL receiver sur un réplica, pg_receivewal. Il peut être aussi tout type de processs qui par le protocole de réplication. that speaks the replication protocol.

Un type de relation utilisé pour générer des valeurs. Typiquement, les valeurs générées sont des nombres séquentiels qui ne se répètent pas. Elles sont habituellement utilisées pour générer des valeurs pour des clés primaires de substitut.

Un ordinateur sur lequel des instances PostgreSQL sont exécutées. Le terme serveur dénote le matériel, un containeur ou une machine virtuelle.

Ce terme est parfois utilisé pour faire référence à une instance ou à un hôte.

Une collection nommée de tables distantes qui utilisent toute le même wrapper de données distantes et ont d'autres valeurs de configuration en commun.

Pour plus d'informations, voir CREATE SERVER.

Un état qui permet à un client et un processus serveur d'interagir, en communiquant au travers d'une connexion.

Une série de documents qui définit le langage SQL.

Un processus auxiliaire qui rejoue les WAL lors d'un redémarrage après crash et dans un réplicat physique.

(Le nom est historique : le processus de démarrage a été nommé avant la réplication. Le nom fait référence à ce tâche car il est en relation avec l'amorçage du serveur après un crash.

Un système qui, une fois activé, accumule des informations statistiques sur les activités de l'instance.

Pour plus d'informations, voir Section 28.2.

Une collection d'enregistrements ayant une structure de données communes (même nombre d'attributs, dans le même ordre, ayant le même nom et le même type par position). Une table est la forme la plus commune de relation dans PostgreSQL.

Pour plus d'informations, voir CREATE TABLE.

Une relation qui apparaît avoir des enregistrements et colonnes similaires à une table régulière, mais qui transfèrent les requêtes de données à travers son wrapper de données distantes, qui retournera les ensembles de résultats structurés selon la définition de la table distante.

Pour plus d'informations, voir CREATE FOREIGN TABLE.

Une relation qui est sémantiquement identique à une table, mais dont le stockage est distribué sur plusieurs partitions.

Tables qui existent soit pour la durée d'une session soit pour la durée d'une transaction, comme indiqué au moment de leur création. Les données de ces tables ne sont pas visibles des autres sessions et ne sont pas journalisées. Les tables temporaires sont souvent utilisées pour enregistrer des données intermédiaires pour une opération en plusieurs étapes.

Pour plus d'informations, voir CREATE TABLE.

Un emplacement nommé sur le système de fichiers du serveur. Tous les objets SQL nécessitant du stockage en dehors de leur définition dans le catalogue système doivent appartenir à un seul tablespace. Au départ, l'instance contient un seul tablespace utilisable et qui est donc le tablespace par défaut pour tous les objets SQL. Ce tablespace est appelé pg_default.

Pour plus d'informations, voir Section 23.6.

Un mécanisme permettant de diviser les valeurs volumineuses des colonnes d'une ligne d'une table et de les enregistrer dans une table secondaire, appelée table TOAST. Chaque relation comprenant des colonnes à taille variable (et donc potentiellement volumineuse) a sa propre table TOAST.

Pour plus d'informations, voir Section 73.2.

Une combinaison de commandes qui agissent comme une seule commande atomique : elles réussissent toutes ou elles échouent toutes, comme une seule unité, et leurs effets ne sont pas visibles pour les autres sessions tant que la transaction n'est pas terminée, et même potentiellement après, suivant le niveau d'isolation.

Pour plus d'informations, voir Section 13.2.

Nombre moyen de transactions exécutées par seconde, totalisées sur toutes les sessions actives pendant un certain temps. C'est utilisé comme une mesure des performances d'une instance.

Une fonction qui peut être définie pour s'exécuter quand une certaine opération (INSERT, UPDATE, DELETE, TRUNCATE) est appliquée à une relation. Un trigger s'exécute dans la même transaction que la requête qui l'a appelé et, si la fonction échoue, alors la requête appelante échoue aussi.

Pour plus d'informations, voir CREATE TRIGGER.

Une commande SQL utilisée pour modifier les lignes qui existeraient déjà dane une table spécifiée. Elle ne peut ni créer ni supprimer des lignes.

Pour plus d'informations, voir UPDATE.

Un role doté de l'attribut de connexions (voir Section 22.2).

Le processus permettant de supprimer les versions de lignes obsolètes des tables ou vues matérialisées, ainsi que d'autres processus en relation proche par l'implémentation PostgreSQL de MVCC. Ce processus est déclenchable en utilisant la commande VACUUM, mais peut aussi être géré automatiquement via les processus autovacuum.

Pour plus d'informations, Section 25.1 .

Un mécanisme qui assure à un processus de limiter ou prévenir des accès simultanés à une ressource.

Une relation qui est définie par la requête SELECT, mais n'a pas de stockage propre. À chaque fois qu'une requête référence une vue, la définition de la vue est substituée dans la requête comme si l'utilisateur l'avait saisi comme une sous-requête à la place du nom de la vue.

Pour plus d'informations, voir CREATE VIEW.

Une relation qui est définie par une expression SELECT (juste comme une vue), mais stocke les données de la même façon qu'une table le fait. Elle ne peut être modifiée via les opérations INSERT, UPDATE, DELETE ou MERGE.

Pour plus d'informations, voir CREATE MATERIALIZED VIEW.

Un processus auxiliaire qui, une fois activé, sauvegarde des copies des fichiers WAL dans le but de créer des sauvegardes ou conserver le réplicas actuel.

Pour plus d'informations, voir Section 26.3.

Un processus auxiliaire qui écrit les enregistrements WAL de la mémoire partagée vers les fichiers WAL.

Pour plus d'informations, voir Section 20.5.

Un moyen de représenter des données qui ne sont pas contenues sur la base de données locale de sorte qu'elles apparaissent comme si elles étaient locales. Avec un wrapper de données distantes, il est possible de définir un serveur distant et des tables distantes.

Pour plus d'informations, voir CREATE FOREIGN DATA WRAPPER.