Le mécanisme WAL est automatiquement activé ; aucune action n'est requise de la part de l'administrateur, sauf s'assurer que l'espace disque requis par les journaux de transaction est présent et que tous les réglages nécessaires sont faits (voir la Section 30.5).

Les enregistrements WAL sont ajoutés aux journaux WAL, enregistrement après enregistrement. La position d'insertion est donnée par le Log Sequence Number (LSN, pour numéro de séquence de journal) qui est un décalage d'octets (offset) au sein des journaux de transactions, qui s'incrémente de manière monotone à chaque enregistrement. Les valeurs du LSN sont renvoyées en tant que type de données pg_lsn. Les valeurs peuvent être comparées pour calculer le volume de données WAL les séparant, permettant ainsi de mesurer l'avancement de la réplication et de la restauration.

Les journaux de transaction sont un ensemble de fichiers stockés dans le répertoire pg_wal sous celui des données, chacun d'une taille de 16 Mo normalement (cette taille pouvant être modifiée en modifiant l'option --wal-segsize d'initdb). Chaque fichier est divisé en pages de généralement 8 ko (cette taille pouvant être modifiée avec l'option --with-wal-blocksize de configure). Les en-têtes d'une entrée de journal sont décrites dans access/xlogrecord.h ; le contenu d'une entrée dépend du type de l'événement qui est enregistré. Les fichiers sont nommés suivant des nombres continûment incrémentés, commençant par 000000010000000000000001. Les nombres ne bouclent pas, mais cela prendra beaucoup, beaucoup de temps pour épuiser le stock de nombres disponibles.

Il est avantageux que les journaux soient situés sur un autre disque que celui des fichiers principaux de la base de données. Cela peut se faire en déplaçant le répertoire pg_wal vers un autre emplacement (serveur arrêté, bien sûr) et en créant dans le répertoire principal de données un lien symbolique de l'emplacement original vers le nouveau.

Le but de WAL est de s'assurer que le journal est écrit avant de modifier les enregistrements de la base, mais cela peut être mis en échec par des disques qui rapportent une écriture réussie au noyau quand, en fait, ils ont seulement mis en cache les données et ne les ont pas encore stockées sur le disque. Une coupure de courant dans ce genre de situation peut mener à une corruption irrécupérable des données. Les administrateurs devraient s'assurer que les disques contenant les journaux de transaction de PostgreSQL ne produisent pas ce genre de faux rapports. (Voir Section 30.1.)

Après qu'un checkpoint a été fait et le journal vidé sur disque, la position du checkpoint est sauvegardée dans le fichier pg_control. Donc, au début de la récupération, le serveur lit en premier pg_control et ensuite l'entrée du checkpoint ; ensuite, il opère le REDO en progressant à partir de la position du journal indiquée dans l'entrée du checkpoint. Parce que l'ensemble du contenu des pages de données est sauvegardé dans le journal à la première modification de page après un checkpoint (en supposant que full_page_writes n'est pas désactivé), toutes les pages modifiées depuis le checkpoint seront restaurées dans un état cohérent.

Pour gérer le cas où pg_control est corrompu, nous devrions permettre le parcours des segments de journaux existants en ordre inverse -- du plus récent au plus ancien -- pour trouver le dernier checkpoint. Ceci n'a pas encore été implémenté. pg_control est assez petit (moins d'une page disque) pour ne pas être sujet aux problèmes d'écriture partielle et, au moment où ceci est écrit, il n'y a eu aucun rapport de défaillance d'une base due uniquement à l'incapacité à lire pg_control. Donc, bien qu'étant théoriquement un point faible, pg_control ne semble pas être un problème en pratique.