25.4. Internamente

O WAL é habilitado automaticamente; não é requerida nenhuma ação por parte do administrador, exceto garantir que a necessidade de espaço em disco adicional para o WAL seja atendida, e que seja feito qualquer ajuste necessário (veja a Seção 25.3 ).

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 com 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 0000000000000000. 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 controle ter sido feito e o registro descarregado, a posição do ponto de controle é 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 controle; em seguida realiza a operação de REDO varrendo para frente a partir da posição indicada pelo registro de ponto de controle. Como na primeira modificação feita em uma página de dados após o ponto de controle é salvo todo o conteúdo desta página, todas as páginas modificadas desde o último ponto de controle serão restauradas para um estado consistente.

A utilização do arquivo pg_control para obter a posição do ponto de controle acelera o processo de recuperação, mas para tratar uma possível corrupção do pg_control deve ser implementada uma leitura dos arquivos de segmento do WAL existentes em sentido contrário (do mais novo para o mais antigo) para poder encontrar o último ponto de controle. Isto ainda não foi implementado.