Vous n'êtes pas identifié(e).
Bonjour,
Je suis à la recherche d'une réponse assez précise concernant la gestion de l'annulation des transactions
non commitées lors d'un arrête brutal/redémarrage d'un cluster postgresql.
Je précise que j'ai une bonne connaissance de ces mécanismes sur d'autres sgbd et j'essaie d'avoir le même
niveau de connaissance sur postgresql :
lorsqu'un checkpoint se produit, il est tout à fait possible que des transactions non commitées soient écrites en bases (dans les fichiers de base de données).
Et donc si un arrêt/redémarrage brutal se produit, la base de données se retrouve dans un état non consistent puisque des transactions non validées ont été écrites sur disque.
Vous allez me dire : nous avons les WAL.
Mais lorsque je lis la documentation postgres, celle-ci insiste de manière exclusive sur le role des WAL pour rejouer les transactions qui n'auraient pas été écrites dans la base de données.
je cite la documentation :
"Write-Ahead Logging (WAL) est une méthode conventionnelle pour s'assurer de l'intégrité des données. Une description détaillée peut être trouvée dans la plupart des livres sur le traitement transactionnel. Brièvement, le concept central du WAL est d'effectuer les changements des fichiers de données (donc les tables et les index) uniquement après que ces changements ont été écrits de façon sûr dans un journal, appelé journal des transactions. Si nous suivons cette procédure, nous n'avons pas besoin d'écrire les pages de données vers le disque à chaque validation de transaction car nous savons que, dans l'éventualité d'une défaillance, nous serons capables de récupérer la base de données en utilisant le journal : chaque changement qui n'a pas été appliqué aux pages de données peut être ré-exécuté depuis les enregistrements du journal (ceci est une récupération roll-forward, aussi connue sous le nom de REDO)".
La notion de roll-forward est ici la seule mentionnée.
mais qu'en est-il du roll-backward qui consiste à annuler les transactions qui n'ont pas été commitées ?
Doit-on comprendre que ces deux notions sont regroupée sous le terme "roll-forward" dans la terminologie postgres ?
Je m'interroge d'autant plus lorque je lis ceci dans la doc us :
"At all times, PostgreSQL maintains a write ahead log (WAL) in the pg_xlog/ subdirectory of the cluster’s
data directory. The log records every change made to the database’s data files. This log exists primarily for
crash-safety purposes: if the system crashes, the database can be restored to consistency by “replaying”
the log entries made since the last checkpoint".
le replay des log entries ne concerne que les log entries qui font suite au dernier checkpoint.
Mais justement, un checkpoint signifie l'écriture sur datafiles des données qui sont en cache, ce qui signifie aussi bien les données commitées que celles non commitées.
A partir de là si tout ce qui précède le dernier checkpoint est ignoré, quid des transaction non commitées, écrites sur disque lors du dernier checkpoint mais non commitées ?
Merci pour votre aide.
Olivier
Hors ligne
J'entrevois une possibilité (mais j'aimerais bien avoir l'avis d'un expert sur le sujet) :
Dans la mesure où postgresql n'utilise pas (comme oracle un mécanisme d'undo) mais une notion de vacuum, il est possible que tout record écrit sur disque mais non commité soit considéré d'emblée comme candidat au vacuum puisque non commité (j'imagine néanmoins que celà doit être plus compliqué que celà, mais expliquerait pourquoi il n'y a que du roll-forward et pas d'anullation de transaction).
Hors ligne
mais qu'en est-il du roll-backward qui consiste à annuler les transactions qui n'ont pas été commitées ?
Une transaction non commitée est considérée comme annulée (rollbackée).
A partir de là si tout ce qui précède le dernier checkpoint est ignoré, quid des transaction non commitées, écrites sur disque lors du dernier checkpoint mais non commitées ?
Si la transaction s'est terminée sans COMMIT, la transaction est considérée comme rollbackée et son identifiant a comme statut rollbacké.
Guillaume.
Hors ligne
Merci beaucoup guillaume.
Réponse claire et précise (et dans un délai plus rapide que le support oracle 
)
Je débute sous postgresql après 14 années passées sur Oracle (que j'aime toujours autant d'un point de vue technique), mais postgresql
est à bien des égards tout à fait séduisant.
A+ pour sans doute d'autres questions.
Hors ligne
Pour faire plus détailler, PostgreSQL maintient sur chaque ligne deux informations. La première correspond à l'identifiant de transaction ayant créé la ligne (suite à un INSERT par exemple), la seconde à l'identifiant ayant supprimé la ligne (suite à un UPDATE ou à un DELETE par exemple). Cet deux identifiants sont directement enregistrés dans la table, dans les colonnes xmin et xmax.
PostgreSQL maintient aussi un tableau indiquant si tel identifiant de transaction est commité ou rollbacké. Ces informations sont stockées dans les fichiers du répertoire pg_clog.
Du coup, si une transaction n'est pas finie (suite à un crash du serveur ou à un crash de l'application cliente ou à un problème réseau ou à je ne sais quoi d'autres), les lignes que cette transaction a ajouté ou supprimée sont tagguées par un identifiant de transaction au statut rollbacké. Du coup PostgreSQL n'en tient pas compte.
L'article http://www.dalibo.org/glmf109_operation … postgresql devrait vous intéressé.
Guillaume.
Hors ligne
Génial ! Merci beaucoup pour ces explications (je me demandais effectivement à quoi servait pg_clog) et pour le lien vers l'article que je vais m'empresser de dévorer
celà fait trois jours que je recherche sur le web des articles sur les internals de postgresql, et là je suis servi. J'ai une facheuse tendance à avoir besoin de comprendre comment
tout fonctionne....
Juste une question :
Comment accédez-vous à ce genre d'information ? Il y a bien sûr le code source, mais je ne suis pas développeur (par contre j'ai remarqué que le code était très bien documenté).
Y a-t-il des fonctions permettant de dumper des blocs et d'examiner leur contenu ?
En tous les cas, je peux vous garantir que le fait de répondre aussi précisément à des question comme les miennes, est le meilleur moyen d'attirer les dba oracle chevronnés !
Encore Merci !
Olivier
Hors ligne
Comment accédez-vous à ce genre d'information ?
Principalement avec la documentation, avec des outils trouvés généralement dans les modules contribs, mais aussi en lisant les sources. Et puis ça fait quand même plus de dix ans que je travaille avec PostgreSQL. Ça aide
Concernant le code, il est vraiment très bien commenté. De plus, vous trouverez des fichiers README par-ci par-là qui seront plus simples à lire que le code lui-même.
Y a-t-il des fonctions permettant de dumper des blocs et d'examiner leur contenu ?
Le module pageinspect donne quelques infos (http://www.postgresql.org/docs/9.2/inte … spect.html) mais je trouve pg_filedump bien plus intéressant (http://pgfoundry.org/projects/pgfiledump/).
En tous les cas, je peux vous garantir que le fait de répondre aussi précisément à des question comme les miennes, est le meilleur moyen d'attirer les dba oracle chevronnés !
Content que ça vous plaise
Bonne suite dans votre découverte de PostgreSQL.
Guillaume.
Hors ligne
Encore Merci pour tout ce partage de connaissance
Olivier
Hors ligne
