O parâmetro wal_level determina quanta informação é escrita no WAL. O padrão é replica, que escreve dados suficientes para dar suporte ao arquivamento do WAL e a replicação, incluindo a execução de instruções que realizam somente leitura em um servidor em-espera (standby). O nível minimal remove todo o registro, exceto das informações necessárias para a restauração de uma falha ou desligamento imediato. Por fim, o nível logical adiciona as informações necessárias para dar suporte à decodificação lógica. Cada nível inclui as informações registradas em todos os níveis inferiores. Este parâmetro só pode ser definido na ativação do servidor.

O nível minimal gera o menor volume de WAL. Não registra informações de linha para relações permanentes em transações que as criam ou reescrevem. Isto pode tornar as operações muito mais rápidas. (veja Desativação do arquivamento do WAL e replicação por fluxo). As operações que iniciam esta otimização incluem:

Entretanto, o WAL mínimo não contém informações suficientes para a restauração em um ponto no tempo (point-in-time recovery); portanto, deve-se utilizar o nível replica ou superior para ativar o arquivamento contínuo (archive_mode) e a replicação binária por fluxo (streaming. Na verdade, o servidor nem sequer iniciará neste modo se max_wal_senders for diferente de zero. Note-se que alterar wal_level para minimal torna as cópias de segurança base anteriores inúteis ​​para restauração em um ponto no tempo e para servidores em-espera (standby servers).

No nível logical, são registradas as mesmas informações que em replica, mais as informações necessárias para permitir extrair os conjuntos de alterações lógicas do WAL. O uso do nível logical aumenta o volume do WAL, particularmente se muitas tabelas estiverem configuradas com REPLICA IDENTITY FULL e forem executados muitos comandos UPDATE e DELETE.

Nas versões anteriores a 9.6, este parâmetro também permitia os níveis archive e hot_standby. Estes níveis ainda são aceitos, mas são mapeados para replica.

Se este parâmetro estiver ativo, o servidor PostgreSQL tentará garantir que as atualizações sejam escritas fisicamente no disco, executando chamadas de sistema fsync(), ou vários métodos equivalentes (veja wal_sync_method). Isto garante que o agrupamento de bancos de dados (instância) possa se restaurar para um estado consistente após uma falha no sistema operacional ou no hardware.

Embora desativar fsync geralmente seja benéfico em termos de desempenho, pode originar uma corrupção irrecuperável dos dados no caso de falta de energia ou travamento do sistema. Portanto, só é aconselhável desativar fsync se for possível recriar facilmente todo o banco de dados a partir de dados externos.

Exemplos de circunstâncias seguras para desativar fsync incluem: a ativação inicial de um novo agrupamento de bancos de dados a partir de arquivo de cópia de segurança; o uso de um agrupamento de bancos de dados para processar um lote de dados, após o que o banco de dados será descartado e recriado; ou para um clone de banco de dados somente de leitura recriado com frequência e não usado para redundância (failover). Equipamento de alta qualidade por si só não é justificativa suficiente para desativar o fsync.

Para uma restauração confiável ao alterar fsync de inativo para ativo, é necessário forçar que todos os buffers modificados no cache do kernel sejam escritos no armazenamento permanente. Isto pode ser feito quando a instância está parada, ou quando fsync é ativado executando initdb --sync-only, executando sync, desmontando o sistema de arquivos, ou reiniciando o servidor.

Em muitas situações, desativar synchronous_commit para transações não críticas pode fornecer grande parte do benefício potencial de desempenho de desativar fsync, sem os riscos inerentes de corrupção dos dados.

O parâmetro fsync só pode ser definido no arquivo postgresql.conf, ou na linha de comando do servidor. Se este parâmetro for desativado, deve-se considera desativar também full_page_writes.

Especifica o quanto do processamento do WAL deve estar concluído antes que o servidor de banco de dados retorne uma indicação de “sucesso” ao cliente. Os valores válidos são remote_apply, on (o padrão), remote_write, local, e off.

Se synchronous_standby_names estiver vazio, as únicas configurações que fazem sentido são on e off; remote_apply, remote_write e local fornecem o mesmo nível de sincronização local que on. O comportamento local de todos os modos diferentes de off é aguardar pela descarga local do WAL para o disco. No modo off, não há espera, então pode haver um atraso entre quando o sucesso é relatado ao cliente e quando a transação é posteriormente garantida como segura contra uma falha do servidor. (O atraso máximo é três vezes wal_writer_delay.) Ao contrário de fsync, configurar este parâmetro como off não cria nenhum risco de inconsistência no banco de dados: uma falha no sistema operacional ou no banco de dados pode resultar na perda de algumas transações recentes supostamente confirmadas, mas o estado do banco de dados será o mesmo como se estas transações tivessem sido interrompidas corretamente. Portanto, desativar synchronous_commit pode ser uma alternativa útil quando o desempenho é mais importante do que a certeza exata sobre a permanência de uma transação. Para obter mais informações veja Efetivação assíncrona.

Se synchronous_standby_names não estiver vazio, então synchronous_commit também controla se as efetivações da transação vão aguardar que seus registros de transação sejam processados no(s) servidor(es) em-espera.

Quando definido como remote_apply, as efetivações vão aguardar até que as respostas do(s) servidor(es) em-espera síncrono(s) corrente(s) indiquem que receberam o registro de efetivação da transação e o aplicaram, de modo que se torne visível para instruções no(s) servidor(es) em-espera, e também escrito no armazenamento permanente nos servidor(es) em-espera. Isto causará atrasos na efetivação muito maiores do que as configurações anteriores, porque aguarda a repetição do WAL. Quando definido como on, as efetivações esperam até que as respostas do(s) servidor(es) em-espera síncrono(s) corrente(s) indiquem que receberam o registro de efetivação da transação, e o liberaram para armazenamento permanente. Isto garante que a transação não será perdida, a menos que o servidor primário e todos os servidores em-espera síncronos sofram corrupção em seu armazenamento de banco de dados. Quando definido como remote_write, as efetivações vão aguardar até que as respostas do(s) servidor(es) em-espera síncrono(s) corrente(s) indiquem que receberam o registro de efetivação da transação e o escreveram em seus sistemas de arquivos. Esta configuração garante a preservação dos dados se uma instância em-espera do PostgreSQL travar, mas não se a instância em-espera sofrer uma falha no nível do sistema operacional, porque os dados não atingiram necessariamente o armazenamento permanente na instância em-espera. A configuração local faz com que as efetivações esperem pela descarga local no disco, mas não pela replicação. Geralmente isto não é desejável quando está sendo usada a replicação síncrona, mas é fornecido para ficar completo.

Este parâmetro pode ser alterado a qualquer momento; o comportamento de qualquer transação é determinado pela configuração em vigor quando a transação é efetivada. Portanto, é possível e útil ter algumas transações efetivadas de forma síncrona e outras de forma assíncrona. Por exemplo, para fazer com que uma única transação com vários comandos efetive de forma assíncrona, quando o padrão é o oposto, deve-se adicionar o comando SET LOCAL synchronous_commit TO OFF à transação.

A Tabela 19.1 resume os recursos de configuração do parâmetro synchronous_commit.

Método usado ao forçar que as atualizações do WAL sejam escritas fisicamente no disco. Se fsync estiver inativo, esta configuração será irrelevante, porque não serão forçadas escritas das atualizações dos arquivos de WAL. Os valores possíveis são:

Nem todas estas opções estão disponíveis em todas as plataformas. O padrão é o primeiro método da lista acima com suporte pela plataforma, exceto pelo fato de que fdatasync é o padrão no Linux e no FreeBSD. O padrão não é necessariamente o ideal; Pode ser necessário alterar esta configuração ou outros aspectos da configuração do sistema para criar uma configuração resistente a falhas ou obter desempenho ideal. Estes aspectos são discutidos em Confiabilidade. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Quando este parâmetro está ativo, o servidor PostgreSQL escreve todo o conteúdo de cada página de disco no WAL durante a primeira modificação dessa página após um ponto de verificação. Isto é necessário, porque uma escrita de página que está em andamento durante a falha do sistema operacional pode ser concluída apenas parcialmente, levando a uma página no disco contendo uma mistura de dados antigos e novos. Os dados de alteração no nível de linha normalmente armazenados no WAL não serão suficientes para restaurar completamente esta página durante a restauração pós-falha. Armazenar a imagem da página inteira garante que a página possa ser restaurada corretamente, mas ao preço de aumentar a quantidade de dados que devem ser escritos no WAL. (Como a reprodução do WAL sempre começa a partir de um ponto de verificação, é suficiente fazer isto durante a primeira alteração de cada página após o ponto de verificação. Portanto, uma maneira de reduzir o custo de escritas de página inteira é aumentar os parâmetros de intervalo do ponto de verificação.)

A desativação desse parâmetro acelera a operação normal, mas pode levar à corrupção irrecuperável dos dados, ou à corrupção silenciosa de dados após uma falha do sistema. Os riscos são semelhantes a desativar fsync, embora menores, devendo ser desativado apenas com base nas mesmas circunstâncias recomendadas para este parâmetro.

A desativação desse parâmetro não afeta o uso do arquivamento do WAL para a restauração para um ponto-no-tempo (PITR) (veja Arquivamento contínuo e restauração para um ponto-no-tempo (PITR)).

Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. O padrão é on.

Quando este parâmetro está definido como on, o servidor PostgreSQL escreve todo o conteúdo de cada página de disco no WAL durante a primeira modificação dessa página após um ponto de verificação, mesmo para modificações não críticas dos chamados bits de dica (hint bits).

Se as somas de verificação (checksums) dos dados estiverem ativas, as atualizações de bit de dica serão sempre registradas no WAL, e esta configuração será ignorada. Esta configuração pode ser usada para testar quanto registro do WAL extra ocorreria se o banco de dados tivesse as somas de verificação dos dados ativas.

Este parâmetro só pode ser definido na ativação do servidor. O padrão é off.

Este parâmetro ativa a compressão do WAL usando o método de compressão especificado. Quando ativo, o servidor PostgreSQL comprime imagens de página completa gravadas no WAL. (por exemplo, quando full_page_writes está ativo, durante uma cópia de segurança base, etc.). Uma imagem de página comprimida será expandida durante a reprodução do WAL. Os métodos com suporte são pglz, lz4 (se o PostgreSQL foi construído com --with-lz4) e zstd (se o PostgreSQL foi construído com --with-zstd). O padrão é off. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Ativar a compressão pode reduzir o volume de WAL sem aumentar o risco de uma corrupção de dados irrecuperável, mas ao custo de um consumo adicional de CPU para a compressão durante a geração de registros do WAL e para a expansão durante a reprodução do WAL.

Quando este parâmetro está definido como on (o padrão), esta opção faz com que os novos arquivos de WAL sejam preenchidos com zeros. Em alguns sistemas de arquivos, isto garante que o espaço seja alocado antes de ser necessário escrever registros do WAL. Entretanto, os sistemas de arquivos Copy-On-Write (COW) podem não se beneficiar dessa técnica, então é dada a opção de evitar o trabalho desnecessário. Se definido como off, apenas o byte final é escrito quando o arquivo é criado, para ter o tamanho esperado.

Quando este parâmetro está definido como on (o padrão), esta opção faz com que os arquivos de WAL sejam reciclados renomeando-os, evitando a necessidade de criar novos. Nos sistemas de arquivos COW pode ser mais rápido criar novos, portanto, é fornecida a opção de desativar este comportamento.

A quantidade de memória compartilhada usada para dados do WAL que ainda não foram escritos em disco. A configuração padrão de -1 seleciona um tamanho igual a 1/32 avos (cerca de 3%) do shared_buffers, mas não menos que 64kB, nem mais do que o tamanho de um segmento de WAL, normalmente de 16MB. Este valor pode ser definido manualmente se a escolha automática for muito grande ou muito pequena, mas qualquer valor positivo menor que 32kB será tratado como 32kB. Se o valor for especificado sem unidade, será considerado sendo blocos de WAL, ou seja, XLOG_BLCKSZ bytes, normalmente 8kB. Este parâmetro só pode ser definido na ativação do servidor.

O conteúdo dos buffers do WAL é escrito no disco a cada efetivação de transação, portanto é improvável que valores extremamente grandes forneçam um benefício significativo. Entretanto, definir este valor para pelo menos alguns megabytes pode melhorar o desempenho de escrita em um servidor ocupado no qual muitos clientes estão efetivando transações ao mesmo tempo. O ajuste automático selecionado pela configuração padrão de -1 deve fornecer resultados razoáveis na maioria dos casos.

Especifica a frequência com que o processo servidor walwriter descarrega o WAL, em termos de tempo. Após descarregar o WAL, o walwriter dorme pelo tempo determinado por wal_writer_delay, a menos que seja acordado antes por uma efetivação de transação assíncrona. Se a última descarga ocorreu há menos de wal_writer_delay atrás, e menos de wal_writer_flush_after de WAL foi produzido desde então, o WAL será escrito apenas no sistema operacional, e não descarregado no disco. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 200 milissegundos (200ms). Note-se que, em muitos sistemas, a resolução efetiva dos atrasos de inatividade é 10 milissegundos; definir wal_writer_delay com um valor que não seja múltiplo de 10 pode ter os mesmos resultados que defini-lo para o próximo múltiplo maior de 10. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica a frequência com que o processo servidor walwriter descarrega o WAL, em termos de volume. Se a última descarga ocorreu há menos de wal_writer_delay atrás, e menos de wal_writer_flush_after de WAL foi produzido desde então, o WAL é escrito apenas no sistema operacional, e não descarregado no disco. Se wal_writer_flush_after for definido como 0, os dados de WAL serão sempre descarregados imediatamente. Se o valor for especificado sem unidade, será considerado sendo blocos de WAL, ou seja, XLOG_BLCKSZ bytes, normalmente 8kB. O padrão é 1MB. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Quando wal_level está definido como minimal, e uma transação é efetivada após criar ou reescrever uma relação permanente, esta configuração determina como os novos dados são persistidos. Se os dados forem menores que esta configuração, são escritos no registro de transações; caso contrário, é usado um pedido de sincronização (fsync) para os arquivos afetados. Dependendo das propriedades do armazenamento, aumentar ou diminuir este valor poderá ajudar, se estas efetivações estiverem retardando as transações concorrentes. Se o valor for especificado sem unidade, será considerado sendo kilobytes. O padrão é 2 megabytes (2MB).

Definir commit_delay adiciona um atraso de tempo antes que a descarga do WAL seja iniciada. Pode melhorar a taxa de transferência de efetivação de grupo, permitindo que um número maior de transações seja efetivado por meio de uma única descarga do WAL, se a carga do sistema for alta o suficiente para que transações adicionais fiquem prontas para efetivação dentro do intervalo especificado. Entretanto, também aumenta a latência em até commit_delay para cada descarga do WAL. Como o atraso é desperdiçado apenas quando nenhuma outra transação está pronta para efetivação, o atraso só será executado se pelo menos commit_siblings outras transações estiverem ativas quando a descarga estiver prestes a ser iniciada. Além disso, nenhum atraso será executado se fsync estiver inativo. Se o valor for especificado sem unidade, será considerado sendo microssegundos. O commit_delay padrão é zero (sem atraso). Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Nas versões do PostgreSQL anteriores a 9.3, o commit_delay se comportava de maneira diferente, e muito menos eficaz: afetava apenas as efetivações, em vez de todas as descargas do WAL, e esperava todo o atraso configurado, mesmo que a descarga do WAL fosse completada mais cedo. A partir do PostgreSQL 9.3, o primeiro processo que fica pronto para descarregar espera pelo intervalo definido, enquanto os processos seguintes esperam apenas até que o líder conclua a operação de descarga.

O número mínimo exigido de transações abertas concorrentes antes de efetuar o atraso commit_delay. Um valor maior aumenta a probabilidade de que alguma outra transação fique pronta para ser efetivada durante o intervalo de atraso. O padrão é 5 transações.

Tempo máximo entre os pontos de verificação (checkpoints) automáticos do WAL. Se o valor for especificado sem unidade, será considerado sendo segundos. O intervalo válido é entre 30 segundos e um dia. O padrão é 5 minutos (5min). Aumentar este parâmetro pode aumentar a quantidade de tempo necessária para restauração de travamento. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica a meta de conclusão do ponto de verificação como uma fração do tempo total entre os pontos de verificação. O padrão é 0.9, que distribui o ponto de verificação por quase todo o intervalo disponível, fornecendo uma carga de E/S bastante consistente e, ao mesmo tempo, deixando algum tempo para a sobrecarga de conclusão do ponto de verificação. A redução desse parâmetro não é recomendada, porque faz com que o ponto de verificação seja concluído mais rapidamente. Isto resulta em uma taxa mais alta de E/S durante o ponto de verificação, seguida por um intervalo com menos E/S entre a conclusão do ponto de verificação e o próximo ponto de verificação agendado. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Sempre que mais do que esta quantidade de dados for escrita durante a execução de um ponto de verificação, tenta forçar o sistema operacional a efetuar estas escritas no armazenamento subjacente. Fazer isto limita a quantidade de dados sujos no cache de página do kernel, reduzindo a probabilidade de interrupções quando a função fsync é chamada no final do ponto de verificação, ou quando o sistema operacional escreve os dados em lotes maiores em segundo plano. Muitas vezes, isto resulta em latência de transação bastante reduzida, mas também há alguns casos, especialmente com cargas de trabalho maiores que shared_buffers, mas menores que o cache de páginas do sistema operacional, em que o desempenho pode diminuir. Esta configuração pode não ter efeito em algumas plataformas. Se o valor for especificado sem unidade, será considerado sendo blocos, ou seja, BLCKSZ bytes, normalmente 8kB. O intervalo válido está entre 0, que desativa o writeback ^[123] forçado, e 2MB. O padrão é 256kB no Linux, e 0 nos demais sistemas operacionais. (Se BLCKSZ não for 8kB, os valores padrão e máximo serão dimensionados proporcionalmente a ele.) Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Escreve uma mensagem no arquivo de registro do servidor (log) se os pontos de verificação causados pelo enchimento de arquivos de segmento de WAL acontecerem mais próximos do que este intervalo de tempo (o que sugere que max_wal_size deve ser aumentado). Se o valor for especificado sem unidade, será considerado sendo segundos. O padrão é 30 segundos (30s). Zero desativa o aviso. Nenhum aviso será gerado se checkpoint_timeout for menor que checkpoint_warning. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Tamanho máximo para deixar o WAL crescer durante os pontos de verificação automáticos. Este é um limite flexível; O tamanho do WAL pode exceder max_wal_size em circunstâncias especiais, como carga intensa, um archive_command ou archive_library com falha, ou uma configuração alta de wal_keep_size. Se o valor for especificado sem unidade, será considerado sendo megabytes. O padrão é 1 GB. Aumentar este parâmetro pode aumentar a quantidade de tempo necessária para restauração após um travamento. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Desde que o uso de disco do WAL permaneça abaixo dessa configuração, os arquivos de WAL antigos serão sempre reciclados para uso futuro em um ponto de verificação, em vez de removidos. Pode ser usado para garantir que seja reservado espaço para o WAL suficiente para lidar com picos de uso do WAL, por exemplo, ao executar grandes tarefas em lote. Se o valor for especificado sem unidade, será considerado sendo megabytes. O padrão é 80 MB. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Quando archive_mode está ativo, os segmentos de registros de transação concluídos podem ser enviados para o arquivamento configurando archive_command ou archive_library. Além de off, para desativar, existem outros dois modos: on e always (sempre). Durante a operação normal, não há diferença entre estes dois modos, mas quando definido como always, o arquivador de registros de transação é ativado também durante a restauração do arquivamento ou no modo em-espera. No modo always, todos os arquivos restaurados do arquivamento, ou transmitidos por fluxo de replicação, são arquivados (novamente). Veja Arquivamento contínuo em servidores em-espera para obter detalhes.

archive_mode é uma configuração separada de archive_command e archive_library para que archive_command e archive_library possam ser alterados sem sair do modo de arquivamento. Este parâmetro só pode ser definido na ativação do servidor. archive_mode não pode ser ativado quando wal_level estiver definido como minimal.

O comando local do interpretador de comandos (shell) a ser executado para arquivamento de um segmento concluído da série de arquivos de WAL. Qualquer ocorrência de %p na cadeia de caracteres é substituída pelo nome do caminho do arquivo a ser enviado para o arquivamento, e qualquer ocorrência de %f é substituída apenas pelo nome do arquivo. (O nome do caminho é relativo ao diretório de trabalho do servidor, ou seja, o diretório de dados da instância.) Deve ser escrito %% para incorporar um caractere % real no comando. É importante que o comando retorne o status de saída zero somente se for bem-sucedido. Para obter mais informações veja Configuração de arquivamento do WAL.

Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. Só será usado se archive_mode estava ativo na ativação do servidor, e archive_library estava definido como uma cadeia de caracteres vazia. Se tanto archive_command quanto archive_library estiverem definidos, será gerado um erro. Se archive_command for uma cadeia de caracteres vazia (o padrão) enquanto archive_mode estiver ativo (e archive_library estiver definido como uma cadeia de caracteres vazia), o arquivamento de WAL estará temporariamente inativo, mas o servidor continuará acumulando arquivos de segmento de WAL, na expectativa de que um comando seja fornecido em breve. Definir archive_command como um comando que não faz nada mas retorna verdade como, por exemplo, /bin/true (REM no Windows), desativa efetivamente o arquivamento, mas também interrompe a cadeia de arquivos de WAL necessária para a restauração a partir dos arquivos; portanto deve ser utilizado apenas em circunstâncias excepcionais.

A biblioteca a ser usada para arquivar segmentos de arquivo de WAL concluídos. Se definido como uma cadeia de caracteres vazia (o padrão), o arquivamento via interpretador de comandos (shell) é ativado e o archive_command será usado. Se tanto archive_command quanto archive_library forem definidos, será gerado um erro. Caso contrário, a biblioteca compartilhada especificada será usada para arquivamento. O processo de arquivamento de WAL é reiniciado pelo postmaster quando este parâmetro é alterado. Para obter mais informações, veja Configuração de arquivamento do WAL e Capítulo 49.

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

O archive_command e o archive_library só são chamados para segmentos de WAL concluídos. Portanto, se o servidor gerar pouco tráfego de WAL (ou tiver períodos de ociosidade), pode haver um longo atraso entre o fim de uma transação e sua escrita segura no arquivamento. Para limitar quão antigo são dos dados não arquivados, pode-se definir archive_timeout para forçar o servidor a alternar para um novo arquivo de segmento do WAL periodicamente. Quando este parâmetro for maior que zero, o servidor mudará para um novo arquivo de segmento sempre que este intervalo de tempo tiver decorrido desde a última troca de arquivo de segmento e houver qualquer atividade no banco de dados, incluindo um único ponto de verificação (os pontos de verificação são suprimidos quando não há atividade no banco de dados). Note-se que os arquivos fechados antecipadamente devido a uma troca forçada ainda têm o mesmo tamanho dos arquivos completamente cheios. Portanto, não é bom usar um archive_timeout muito curto — isto aumentará o tamanho do arquivamento. As configurações de archive_timeout de um minuto ou mais são geralmente razoáveis. Deve-se considerar o uso de fluxo de replicação, em vez de arquivamento, se for desejado que os dados sejam copiados do servidor primário mais rapidamente do que isto. Se o valor for especificado sem unidade, será considerado sendo segundos. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Se deve-se tentar pré-carregar (prefetch) os blocos referenciados no WAL que ainda não estão no grupamento (pool) de buffers durante a restauração. Os valores válidos são off, on e try (o padrão). A configuração try ativa o pré-carregamento apenas se o sistema operacional oferecer suporte para emitir conselho de leitura à frente (read-ahead advice) ^[124].

O pré-carregamento de blocos que serão necessários em breve pode reduzir os tempos de espera de E/S durante a restauração em algumas cargas de trabalho. Veja também as definições de wal_decode_buffer_size e maintenance_io_concurrency, que limitam a atividade de pré-carregamento.

Limita quão à frente o servidor pode olhar no WAL a fim de encontrar blocos para pré-busca. Se este valor for especificado sem unidade, será considerado sendo bytes. O padrão é 512 kB. Este parâmetro só pode ser definido na ativação do servidor.

O comando local do interpretador de comandos (shell) a ser executado para restaurar um segmento arquivado da série de arquivos de WAL. Este parâmetro é necessário para restauração de arquivamento, mas opcional em replicação por fluxo. Qualquer ocorrência de %f na cadeia de caracteres é substituída pelo nome do arquivo a ser restaurado do diretório de arquivamento, e qualquer ocorrência de %p é substituída pelo nome do caminho de destino da cópia no servidor. (O nome do caminho é relativo ao diretório de trabalho corrente, ou seja, o diretório de dados da instância.) Qualquer ocorrência de %r é substituída pelo nome do arquivo que contém o último ponto de reinício válido. Este é o arquivo mais antigo que deve ser mantido para permitir que a restauração seja reiniciada, portanto, estas informações podem ser usadas para reduzir o diretório de arquivamento para apenas o mínimo necessário para dar suporte ao reinício da restauração corrente. Normalmente é usado %r apenas em configurações warm-standby ^[125] (veja Servidores em-espera de envio de registros). Deve ser escrito %% para incorporar um caractere % real na linha de comando.

É importante que o comando retorne o status de saída zero somente se for bem-sucedido. O comando tem de lidar com o fato de arquivos não estarem presentes no arquivamento; neste caso, tem que retornar um código de saída diferente de zero. Exemplos:

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

Uma exceção é que se o comando foi finalizado por um sinal (diferente de SIGTERM, usado como parte do desligamento do servidor de banco de dados), ou um erro do interpretador de comandos (como comando não encontrado), a restauração será interrompida e o servidor não será iniciado.

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

Este parâmetro opcional especifica o comando do interpretador de comandos (shell) que será executado em cada ponto de reinício. O objetivo do archive_cleanup_command é fornecer um mecanismo para limpar os arquivos de WAL antigos arquivados, que não são mais necessários para o servidor em-espera. Qualquer ocorrência de %r é substituída pelo nome do arquivo que contém o último ponto de reinício válido. Este é o arquivo mais antigo que deve ser mantido para permitir que a restauração seja reiniciada e, portanto, todos os arquivos anteriores a %r podem ser removidos com segurança. Estas informações podem ser usadas para reduzir o diretório de arquivamento apenas para o mínimo necessário para dar suporte ao reinício da restauração corrente. O módulo pg_archivecleanup é frequentemente usado em archive_cleanup_command para configurações em espera única, por exemplo:

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

Note-se, no entanto, que se vários servidores em-espera estiverem restaurando a partir do mesmo diretório de arquivamento, será necessário garantir que não se exclua os arquivos de WAL até que não sejam mais necessários para nenhum dos servidores em-espera. Normalmente archive_cleanup_command seria usado em uma configuração warm-standby (veja Servidores em-espera de envio de registros). Deve ser escrito %% para incorporar um caractere % real na linha de comando.

Se o comando retornar um status de saída diferente de zero, então será escrita uma mensagem de aviso no arquivo de registro do servidor (log). Uma exceção é que, se o comando for encerrado por um sinal ou um erro do interpretador de comandos (como comando não encontrado), será gerado um erro fatal.

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

Este parâmetro especifica o comando do interpretador de comandos que será executado apenas uma vez no final da restauração. Este parâmetro é opcional. A finalidade de recovery_end_command é fornecer um mecanismo para limpeza após a replicação ou a restauração. Qualquer ocorrência de %r é substituída pelo nome do arquivo que contém o último ponto de reinício válido, como em archive_cleanup_command.

Se o comando retornar um status de saída diferente de zero, será escrita uma mensagem de aviso no arquivo de registro do servidor, e o banco de dados continuará a carregar de qualquer maneira. Uma exceção é que, se o comando for encerrado por um sinal, ou erro do interpretador de comandos (como comando não encontrado), o banco de dados não continuará a ser carregado.

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

Este parâmetro especifica que a restauração deve terminar assim que um estado consistente for alcançado, ou seja, o mais cedo possível. Ao restaurar de uma cópia de segurança, isto significa o ponto em que a cópia de segurança terminou.

Tecnicamente este é um parâmetro de cadeia de caracteres, mas no momento 'immediate' é o único valor permitido.

Este parâmetro especifica o nome do ponto de restauração (criado com pg_create_restore_point()), até o qual a restauração irá prosseguir.

Este parâmetro especifica o carimbo de data e hora até o qual a restauração irá prosseguir. O ponto de parada preciso também é influenciado por recovery_target_inclusive.

O valor desse parâmetro é um carimbo de data e hora no mesmo formato aceito pelo tipo de dados timestamp with time zone, exceto por não se poder usar uma abreviatura de zona horária (a menos que a variável timezone_abbreviations tenha sido definida anteriormente no arquivo de configuração). O estilo preferido é usar um deslocamento numérico com relação a UTC, ou pode-se escrever um nome de zona horária completo, por exemplo, Europe/Helsinki, e não EEST.

Este parâmetro especifica o identificador de transação até o qual a restauração irá prosseguir. Lembre-se de que, embora os IDs de transação sejam atribuídos sequencialmente no início da transação, as transações podem ser concluídas em uma ordem numérica diferente. As transações que serão restauradas são aquelas efetivadas antes (e opcionalmente incluindo) a transação especificada. O ponto de parada preciso também é influenciado por recovery_target_inclusive.

Este parâmetro especifica o LSN (Log Sequence Number) do local do WAL até o qual a restauração irá prosseguir. O ponto de parada preciso também é influenciado por recovery_target_inclusive. Este parâmetro é analisado usando o Tipo de dados pg_lsn do sistema.

Especifica se deve parar logo após o limite de restauração especificado (on), ou logo antes do limite de restauração (off). Aplica-se quando recovery_target_lsn, recovery_target_time, ou recovery_target_xid é especificado. Esta configuração controla se as transações no limite do local do WAL (LSN), hora de efetivação, ou ID da transação, respectivamente, serão incluídas na restauração. O padrão é on.

Especifica a restauração em uma linha de tempo específica. O valor pode ser um ID numérico da linha do tempo ou um valor especial. O valor current restaura ao longo da mesma linha do tempo que era corrente quando a cópia de segurança base foi feita. O valor latest restaura para a linha do tempo mais recente encontrada no arquivamento, o que é útil em um servidor em-espera. O padrão é latest.

Para especificar um ID de linha do tempo em hexadecimal (por exemplo, se extraído de um nome de arquivo de WAL ou de um arquivo de histórico), deve ser adicionado o prefixo 0x. Por exemplo, se o nome do arquivo de WAL for 00000011000000A10000004F, então o ID da linha do tempo será 0x11 (ou 17 em decimal).

Geralmente só é necessário definir este parâmetro em situações complexas de re-restauração, nas quais é preciso retornar a um estado alcançado após uma restauração para um ponto-no-tempo. Veja Linhas do tempo para obter detalhes.

Especifica qual ação o servidor deve executar quando o limite de restauração for atingido. O padrão é pause, significando que a restauração será pausada. O valor promote significa que o processo de restauração irá terminar, e o servidor começará a aceitar conexões. Por fim, shutdown irá parar o servidor após atingir o limite de restauração.

O uso pretendido da configuração pause é permitir que sejam executadas instruções no banco de dados para verificar se este limite de restauração é o ponto mais desejável para restauração. O estado de pausa pode ser interrompido usando pg_wal_replay_resume() (veja a Tabela 9.99), que faz então com que a restauração termine. Se este limite de restauração não for o ponto de parada desejado, o servidor deverá ser parado, alterada as configurações do limite de restauração para um limite posterior, e reiniciado para continuar a restauração.

A configuração shutdown serve para ter a instância pronta no ponto de reprodução exato desejado. A instância ainda poderá reproduzir mais registros de WAL (e de fato terá que reproduzir os registros de WAL desde o último ponto de verificação na próxima vez que for iniciada).

Note-se que, como recovery.signal não será removido quando recovery_target_action for definido como shutdown, qualquer início posterior terminará com desligamento imediato, a menos que a configuração seja alterada, ou o arquivo recovery.signal seja removido manualmente.

Esta configuração não terá efeito se não for definido nenhum limite de restauração. Se hot_standby ^[126] não estiver ativo, a configuração de pause agirá da mesma forma que shutdown. Se o limite da restauração for atingido enquanto uma promoção estiver em andamento, uma configuração de pause agirá da mesma forma que promote.

Em qualquer caso, se for configurado o limite de restauração, mas a restauração do arquivo terminar antes que o limite seja atingido, o servidor irá parar com um erro fatal.

Ativa o processo de resumir o WAL. Note-se que o resumo do WAL pode ser ativado tanto em um servidor primário quanto em um servidor em-espera. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. O padrão é off.

O servidor não poderá ser ativado com summarize_wal=on se wal_level estiver definido como minimal. Se for configurado summarize_wal=on após a ativação do servidor enquanto wal_level=minimal, o processo de resumir será executado, mas se recusará a gerar arquivos de resumo para qualquer WAL gerado com wal_level=minimal.

Configura o intervalo de tempo após o qual o processo de resumir o WAL remove automaticamente resumos de WAL antigos. O carimbo de data e hora do arquivo é usado para determinar quais arquivos são antigos o suficiente para serem removidos. Normalmente deve-se definir este valor com uma margem de segurança acima do tempo que poderia transcorrer entre uma cópia de segurança e uma cópia de segurança incremental posterior que dependa dela. Os resumos de WAL devem estar disponíveis para todo o intervalo de registros de WAL entre a cópia de segurança anterior e o nova que está sendo realizada; caso contrário, a cópia de segurança incremental irá falhar. Se este parâmetro for definido como zero, os resumos de WAL não serão excluídos automaticamente; no entanto, é seguro remover manualmente os arquivos que se sabe que não serão necessários para futuras cópias de segurança incrementais. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. Se este valor for especificado sem unidade, será considerado sendo minutos. O padrão é 10 dias. Se summarize_wal = off, os resumos de WAL existentes não serão removidos, independentemente do valor deste parâmetro, porque o processo de resumo do WAL não será executado.