25.3. Internamente

O WAL é ativado automaticamente; não é requerida nenhuma ação por parte do administrador, exceto garantir que o espaço em disco adicional necessário para o WAL seja atendido, e que seja feito qualquer ajuste necessário (consulte a Seção 25.2).

O WAL é armazenado no diretório pg_xlog, sob o diretório de dados, como um conjunto de arquivos de segmento, normalmente com o tamanho de 16 MB cada. Cada segmento é dividido em páginas, normalmente de 8 kB cada. Os cabeçalhos dos registro estão descritos em access/xlog.h; o conteúdo do registro depende do tipo de evento que está sendo registrado. São atribuídos para nomes dos arquivos de segmento números que sempre aumentam, começando por 000000010000000000000000. Atualmente os números não recomeçam, mas deve demorar muito tempo até que seja exaurido o estoque de números disponíveis.

Os buffers do WAL e estruturas de controle ficam na memória compartilhada e são tratados pelos processos servidor filhos; são protegidos por bloqueios de peso leve. A demanda por memória compartilhada é dependente do número de buffers. O tamanho padrão dos buffers do WAL é 8 buffers de 8 kB cada um, ou um total de 64 kB.

É vantajoso o WAL ficar localizado em um disco diferente do que ficam os arquivos de banco de dados principais. Isto pode ser obtido movendo o diretório pg_xlog para outro local (enquanto o servidor estiver parado, é óbvio), e criando um vínculo simbólico do local original no diretório de dados principal para o novo local.

A finalidade do WAL, garantir que a alteração seja registrada antes que as linhas do banco de dados sejam alteradas, pode ser subvertida pelos controladores de disco (drives) que informam ao núcleo uma escrita bem-sucedida falsa, e na verdade apenas colocam os dados no cache sem armazenar no disco. Numa situação como esta a queda de energia pode conduzir a uma corrupção dos dados não recuperável. Os administradores devem tentar garantir que os discos que armazenam os arquivos de segmento do WAL do PostgreSQL não fazem estes falsos relatos.

Após um ponto de verificação ter sido feito e o registro descarregado, a posição do ponto de verificação é salva no arquivo pg_control. Portanto, quando uma recuperação vai ser feita o servidor lê primeiro pg_control, e depois o registro de ponto de verificação; em seguida realiza a operação de REDO varrendo para frente a partir da posição indicada pelo registro de ponto de verificação. Como, após o ponto de verificação, na primeira modificação feita em uma página de dados é salvo todo o conteúdo desta página, todas as páginas modificadas desde o último ponto de verificação serão restauradas para um estado consistente.

Para tratar o caso em que o arquivo pg_control foi danificado, é necessário haver suporte para a possibilidade de varrer os arquivos de segmento do WAL em sentido contrário — mais novo para o mais antigo — para encontrar o último ponto de verificação. Isto ainda não foi implementado. O arquivo pg_control é pequeno o suficiente (menos que uma página de disco) para não estar sujeito a problemas de escrita parcial, e até o momento em que esta documentação foi escrita não haviam relatos de falhas do banco de dados devido unicamente a incapacidade de ler o arquivo pg_control. Portanto, embora este seja teoricamente um ponto fraco, na prática o arquivo pg_control não parece ser um problema.