O registro prévio da escrita (WAL = write ahead logging) é uma abordagem padrão para registrar transações. A descrição detalhada pode ser encontrada na maioria (se não em todos) os livros sobre processamento de transação. Em poucas palavras, o conceito central do WAL é que as alterações nos arquivos de dados (onde as tabelas e os índices residem) devem ser escritas somente após estas alterações terem sido registradas, ou seja, quando os registros que descrevem as alterações tiverem sido descarregados em um meio de armazenamento permanente. Se este procedimento for seguido, não será necessário descarregar as páginas de dados no disco a cada efetivação de transação, porque se sabe que no evento de uma queda será possível recuperar o banco de dados utilizando o registro: todas as alterações que não foram aplicadas às páginas de dados são refeitas a partir dos registros (isto é a recuperação de rolar para a frente, roll-forward, também conhecida como REDO),
O primeiro grande benefício da utilização do WAL é a redução significativa do número de escritas em disco, uma vez que na hora em que a transação é efetivada somente precisa ser descarregado em disco o arquivo de registro, em vez de todos os arquivos de dados modificados pela transação. Em ambiente multiusuário, a efetivação de várias transações pode ser feita através de um único fsync() do arquivo de registro. Além disso, o arquivo de registro é escrito seqüencialmente e, portanto, o custo de sincronizar o registro é muito menor do que o custo de descarregar as páginas de dados. Isto é especialmente verdade em servidores tratando muitas transações pequenas afetando partes diferentes do armazenamento de dados.
O benefício seguinte é a consistência das páginas de dados. A verdade é que antes do WAL o PostgreSQL nunca foi capaz de garantir a consistência no caso de uma queda. Antes do WAL, qualquer queda durante a escrita poderia resultar em:
linhas de índice apontando para linhas inexistentes da tabela
perda de linhas de índice nas operações de quebra de página (split)
conteúdo da página da tabela ou do índice totalmente danificado, por causa das páginas de dados parcialmente escritas
Os problemas com os índices (problemas 1 e 2) possivelmente poderiam ter sido resolvidos através de chamadas adicionais à função fsync(), mas não é óbvio como tratar o último caso sem o WAL; se for necessário, o WAL salva todo o conteúdo da página de dados no registro, para garantir a consistência da página na recuperação após a queda.
Por fim, o WAL permite que seja feita cópia de segurança em linha e recuperação para um ponto no tempo, conforme descrito na Seção 22.3. Fazendo cópia dos arquivos de segmento do WAL pode-se retornar para qualquer instante no tempo coberto pelos registros do WAL: simplesmente se instala uma versão anterior da cópia de segurança física do banco de dados, e se refaz o WAL até o ponto desejado no tempo. Além disso, a cópia de segurança física não precisa ser um instantâneo do estado do banco de dados — se a cópia for realizada durante um período de tempo, quando o WAL for refeito para este período de tempo da cópia serão corrigidas todas as inconsistências internas.
