WAL включен автоматически; от администратора не требуется никаких действий, кроме обеспечения выполнения требований к дисковому пространству для файлов WAL и выполнения необходимой настройки (см. Раздел 28.5).

WAL записи добавляются в файлы WAL по мере записи каждого нового записи. Позиция вставки описывается номером последовательности журнала (LSN), который является смещением в байтах в WAL, увеличивающимся монотонно с каждой новой записью. Значения LSN возвращаются как тип данных pg_lsn. Значения могут быть сравнены для расчета объема данных WAL, которые их разделяют, поэтому они используются для измерения прогресса репликации и восстановления.

WAL файлы хранятся в каталоге pg_wal под каталогом данных, в виде набора сегментных файлов, обычно размером по 16 МБ каждый (но размер можно изменить, изменив параметр --wal-segsize в опции initdb). Каждый сегмент разделен на страницы, обычно по 8 кБ каждая (этот размер можно изменить с помощью опции конфигурации --with-wal-blocksize). Заголовки записей WAL описаны в access/xlogrecord.h; содержимое записи зависит от типа события, которое регистрируется. Сегментные файлы получают постоянно увеличивающиеся номера в качестве имен, начиная с 000000010000000000000001. Номера не обнуляются, но потребуется очень, очень много времени, чтобы исчерпать доступный запас номеров.

Это выгодно, если WAL находится на другом диске, чем основные файлы базы данных. Это можно сделать, переместив каталог pg_wal в другое место (конечно, при выключенном сервере) и создав символическую ссылку из исходного расположения в основном каталоге данных в новое место.

Целью WAL является гарантировать, что журнал будет записан перед изменением записей в базе данных, но это может быть нарушено дисками. которые ложно сообщают об успешной записи в ядро, когда на самом деле они только кэшировали данные и еще не сохранили их на диск. Отключение питания в такой ситуации может привести к непоправимой порче данных. Администраторам следует попытаться убедиться, что диски, содержащие файлы Tantor BE's WAL, не делают таких ложных отчетов. (См. Раздел 28.1.)

После создания контрольной точки и сброса WAL, позиция контрольной точки сохраняется в файле pg_control. Поэтому при начале восстановления сервер сначала читает pg_control, а затем запись контрольной точки; затем он выполняет операцию REDO, сканируя вперед от местоположения WAL, указанного в записи контрольной точки. Поскольку все содержимое страниц данных сохраняется в WAL при первом изменении страницы после контрольной точки (при условии, что full_page_writes не отключен), все страницы, измененные с момента контрольной точки, будут восстановлены в согласованное состояние.

Чтобы справиться с случаем, когда pg_control поврежден, мы должны поддерживать возможность сканирования существующих сегментов WAL в обратном порядке — от новейшего к старейшему — чтобы найти последнюю контрольную точку. Это еще не реализовано. pg_control достаточно мал (менее одной страницы диска), чтобы не подвергаться проблемам частичной записи, и на момент написания не было сообщений о сбоях базы данных, вызванных исключительно невозможностью прочитать сам pg_control. Таким образом, хотя теоретически это слабое место, на практике pg_control не кажется проблемой.