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

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

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

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

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

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

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