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 esta função é necessária quando estes arquivos ficam corrompidos. Deve ser utilizada apenas como último recurso, quando o servidor não iniciar por causa da corrupção destes arquivos.
Após executar este comando deve ser possível iniciar o servidor, mas deve-se ter em mente que o banco de dados pode conter dados inconsistentes devido à presença de 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/gravação 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 localização 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 localização; 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 o -f ainda pode ser usado, mas o banco de dados recuperado deve 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. Um valor seguro para o identificador da próxima transação pode ser determinado verificando 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 duas partes. Por exemplo, se 000000FF0000003A for a maior entrada em pg_xlog, então -l 0xFF,0x3B servirá. 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. Isto é principalmente uma ferramenta de depuração, mas pode ser útil para fazer uma verificação antes de permitir que a aplicaçã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; neste caso, o arquivo de bloqueio deve ser removido para permitir o pg_resetxlog executar, mas antes de remover deve-se ter certeza que nem o postmaster, nem nenhum processo servidor, ainda está executando.