Se estiver ativo, qualquer erro irá encerrar a sessão corrente. Por padrão está inativo, de modo que apenas erros do tipo FATAL vão encerrar a sessão.

Quando ativo, o padrão, o PostgreSQL será reiniciado automaticamente após uma falha do processo servidor. Deixar este parâmetro ativo é normalmente a melhor maneira de maximizar a disponibilidade do banco de dados. Entretanto, em algumas circunstâncias, como quando o PostgreSQL está sendo ativado por um gerenciador de instâncias (clusterware), pode ser útil desativar o reinício automático para que o gerenciador de instâncias possa obter controle e executar as ações que considerar apropriadas.

Este parâmetro só pode ser definido no arquivo postgresql.conf, ou na linha de comando do servidor.

Quando inativo, o padrão, o PostgreSQL irá gerar um erro no nível PANIC em caso de falha na descarga dos arquivos de dados modificados para o sistema de arquivos. Isto faz com que o servidor de banco de dados trave. Este parâmetro só pode ser definido na carga do servidor.

Em alguns sistemas operacionais, o status dos dados no cache de páginas do kernel é desconhecido após uma falha de escrever de volta (write-back). Em alguns casos, pode ter sido totalmente esquecido, tornando inseguro tentar novamente; a segunda tentativa pode ser relatada como bem-sucedida, quando, na verdade, os dados foram perdidos. Nessas circunstâncias, a única maneira de evitar a perda de dados é a recuperação a partir do WAL após qualquer falha ser relatada, de preferência após investigar a causa raiz da falha, e substituir qualquer hardware defeituoso.

Se estiver ativo, o PostgreSQL irá reportar um erro, mas continuará executando para que a operação de descarga dos dados possa ser repetida em um ponto de verificação posterior. Somente deve ser ativado após investigar o tratamento dado pelo sistema operacional aos dados armazenados em buffer no caso de falha de escrever de volta (write-back).

Quando definido como fsync, que é o padrão, o PostgreSQL irá abrir e sincronizar recursivamente todos os arquivos no diretório de dados antes do início da recuperação de falhas. A procuras por arquivos seguirá as ligações simbólicas para o diretório do WAL, e cada espaço de tabelas configurado (mas não quaisquer outras ligações simbólicas). O objetivo é garantir que todos os arquivos de WAL e de dados sejam armazenados de forma durável no disco antes de reproduzir as alterações. Isto se aplica sempre que for iniciada uma instância de banco de dados que não foi encerrada corretamente, incluindo cópias criadas com pg_basebackup.

No Linux, pode ser usado syncfs para solicitar ao sistema operacional que sincronize os sistemas de arquivos que contêm o diretório de dados, os arquivos de WAL, e cada espaço de tabelas (mas não quaisquer outros sistemas de arquivos que possam ser acessados através de ligações simbólicas). Isto pode ser muito mais rápido que a configuração fsync, porque não é necessário abrir cada arquivo um por um. Por outro lado, pode ser mais lento se o sistema de arquivos for compartilhado por outras aplicações que modificam muitos arquivos, uma vez que estes arquivos também serão escritos no disco. Além disso, nas versões do Linux anteriores à 5.8, os erros de E/S encontrados durante a escrita de dados no disco podem não ser relatados ao PostgreSQL, e mensagens de erro relevantes podem aparecer apenas nos registros do kernel.

Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.