pg_resetxlog [ -f ] [ -n ] [ -o oid ] [ -x xid ] [ -l timelineid,fileid,seg ] diretório_de_dados
O utilitário pg_resetxlog limpa o log de escrita prévia (WAL) e, opcionalmente, redefine algumas outras informações de controle armazenadas no arquivo pg_control. Algumas vezes este utilitário é necessário quando estes arquivos ficam danificados. Deve ser utilizado apenas como último recurso, quando o servidor não iniciar devido a estes arquivos estarem danificados.
Após executar este comando deve ser possível iniciar o servidor, mas deve-se ter em mente que o banco de dados poderá conter dados inconsistentes devido a transações parcialmente efetivadas. Deve ser feita, imediatamente, uma cópia de segurança dos dados, executar o initdb e recarregar os dados. Após a recarga as inconsistências devem ser verificadas e corrigidas conforme necessário.
Este utilitário pode ser executado apenas pelo usuário que instalou o servidor, porque requer acesso de leitura/escrita no diretório de dados. Por motivo de segurança, o diretório de dados deve ser especificado na linha de comando. O pg_resetxlog não utiliza a variável de ambiente PGDATA.
Se o pg_resetxlog informar que não está conseguindo determinar os dados válidos para pg_control, pode ser forçado a prosseguir assim mesmo especificando a chave -f (forçar). Neste caso, são utilizados valores plausíveis para os dados que estão faltando. Pode-se esperar que a maioria dos campos correspondam, mas pode ser necessário auxílio manual para os campos próximo OID, próximo ID de transação, endereço inicial do WAL e idioma do banco de dados. Os três primeiros podem ser definidos usando as chaves discutidas abaixo. O próprio ambiente do pg_resetxlog é a fonte para os campos de idioma; deve-se cuidar para que LANG e as demais variáveis de ambiente análogas correspondam ao ambiente em que o initdb foi executado. Se não for possível determinar o valor correto para todos estes campos a chave -f ainda poderá ser usada, mas o banco de dados recuperado deverá ser tratado como ainda mais suspeito que o usual: uma imediata cópia de segurança e sua recarga é imperativa. Não deve ser executada nenhuma operação que modifique os dados do banco de dados antes de ser feita a cópia de segurança, porque uma atividade deste tipo pode piorar ainda mais a situação.
As chaves -o, -x e -l permitem definir manualmente o próximo OID, o próximo ID de transação e o endereço inicial do WAL. Somente são necessários quando pg_resetxlog não for capaz de determinar os valores apropriados por meio da leitura do arquivo pg_control. Pode ser determinado um valor seguro para o próximo identificador de transação descobrindo o nome de arquivo com o maior valor numérico no diretório /pg_clog sob o diretório de dados, somando um, e depois multiplicando por 1.048.576. Deve ser observado que os nomes dos arquivos estão em hexadecimal. Normalmente é mais fácil especificar o valor da chave em hexadecimal também. Por exemplo, se 0011 for a maior entrada em pg_clog, então -x 0x1200000 servirá (cinco zeros à direita fornecem o multiplicador apropriado). O endereço inicial do WAL deve ser maior do que qualquer nome de arquivo existente no diretório /pg_xlog sob o diretório de dados. Estes nomes também estão em hexadecimal, e possuem três partes. A primeira parte é o "timeline ID" e deve, geralmente, ser mantido o mesmo. Não deve ser escolhido um valor maior que 255 (0xFF) para a terceira parte; em vez disso, a segunda parte deve ser incrementada e a terceira parte deve ser redefinida como 0. Por exemplo, se a maior entrada em pg_xlog for 00000001000000320000004A, -l 0x1,0x32,0x4B servirá; mas se a maior entrada for 000000010000003A000000FF, então deverá ser escolhido -l 0x1,0x3B,0x0 ou maior. Não existe nenhuma forma mais fácil para determinar o próximo OID acima do maior existente no banco de dados, mas por sorte não é crítico definir o próximo OID corretamente.
A chave -n (nenhuma operação) faz o pg_resetxlog mostrar os valores reconstruídos a partir de pg_control e terminar em seguida, sem modificar nada. Esta é principalmente uma ferramenta de depuração, mas pode ser útil para fazer uma verificação de integridade antes de permitir que o pg_resetxlog realmente efetue a operação.
Este comando não deve ser usado quando o servidor estiver executando. O pg_resetxlog se recusa a iniciar quando encontra o arquivo de bloqueio do servidor no diretório de dados. Se o servidor caiu, então o arquivo de bloqueio pode ter sido deixado no diretório de dados; neste caso, o arquivo de bloqueio deverá ser removido para permitir que o pg_resetxlog execute, mas antes de remover o arquivo de bloqueio deve-se ter certeza que nem o postmaster, nem nenhum processo servidor, ainda está executando.
