Especifica o número máximo de conexões simultâneas de servidores em-espera, ou clientes de cópia de segurança base, por fluxo (ou seja, o número máximo de processos que enviam dados do WAL (walsender) em execução simultânea). O padrão é 10. O valor 0 significa que a replicação por fluxo está desativada. A desconexão abrupta de um cliente de fluxo pode deixar um encaixe (slot) de conexão órfão para trás, até que o tempo limite seja atingido, portanto, este parâmetro deve ser definido um pouco acima do número máximo de clientes esperados para que os clientes desconectados possam se reconectar imediatamente. Este parâmetro só pode ser definido na ativação do servidor. Além disso, wal_level deve ser definido como replica ou superior para permitir conexões de servidores em-espera.

Ao executar um servidor em-espera, deve-se definir este parâmetro com o mesmo valor, ou um valor superior ao do servidor primário. Caso contrário, não serão permitidas consultas no servidor em-espera.

Especifica o número máximo de encaixes de replicação (veja Encaixes de replicação) que o servidor pode dar suporte. O padrão é 10. Este parâmetro só pode ser definido na ativação do servidor. Definir como um valor inferior ao número de encaixes de replicação existentes impedirá que o servidor seja carregado. Além disso, wal_level deve ser definido como replica, ou superior, para permitir o uso de encaixes de replicação.

Especifica o tamanho mínimo de arquivos de WAL antigos mantidos no diretório pg_wal, caso um servidor em-espera precise buscá-los para replicação por fluxo. Se um servidor em-espera conectado ao servidor de envio ficar atrasado em mais de wal_keep_size megabytes, o servidor de envio poderá remover um segmento do WAL ainda necessário para o servidor em-espera, caso em que a conexão de replicação será fechada. As conexões em cascata também vão falhar como resultado. (Entretanto, o servidor em-espera poderá se recuperar buscando o segmento no arquivamento, se estiver sendo usado arquivamento de WAL.)

Este parâmetro define apenas o tamanho mínimo dos segmentos retidos no diretório pg_wal; o sistema pode precisar reter mais segmentos para arquivamento do WAL, ou recuperar de um ponto de verificação. Se wal_keep_size for zero (o padrão), o sistema não manterá nenhum segmento extra para fins de espera, portanto, o número de segmentos antigos de WAL disponíveis para os servidores em-espera é função da localização do ponto de verificação anterior e do status do arquivamento do WAL. Se o valor for especificado sem unidade, será considerado sendo megabytes. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica o tamanho máximo dos arquivos de WAL que Encaixes de replicação pode reter no diretório pg_wal no momento do ponto de verificação. Se max_slot_wal_keep_size for -1 (o padrão), os encaixes de replicação podem reter uma quantidade ilimitada de arquivos de WAL. Caso contrário, se o restart_lsn de um encaixe de replicação ficar atrás do LSN corrente em mais do que o tamanho especificado, o servidor em-espera usando o encaixe poderá não ser mais capaz de continuar a replicação devido à remoção dos arquivos de WAL necessários. Pode-se ver os encaixes de replicação existentes na instância na visão pg_replication_slots. Se o valor for especificado sem unidade, será considerado sendo megabytes. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Invalida os encaixes de replicação que tenham permanecido inativos (não usados por uma conexão de replicação) por um tempo superior a esta duração. Se este valor for especificado sem unidade, será considerado sendo segundos. Um valor zero (o padrão) desativa o mecanismo de invalidação por tempo limite de inatividade. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

A invalidação de encaixe devido ao tempo limite de inatividade ocorre durante o ponto de verificação. Como os pontos de verificação ocorrem em intervalos de checkpoint_timeout, poderá haver algum atraso entre o momento em que o idle_replication_slot_timeout foi excedido e o momento em que a invalidação do encaixe será disparada no próximo ponto de verificação. Para evitar estes atrasos, os usuários podem forçar um ponto de verificação para invalidar prontamente os encaixes inativos. A duração da inatividade do encaixe é calculada usando o valor de pg_replication_slots.inactive_since do encaixe.

Note-se que o mecanismo de invalidação por tempo limite de inatividade não se aplica a encaixes que não reservam WAL, ou a encaixes em servidores em-espera que estão sendo sincronizados a partir do servidor primário. (ou seja, encaixes de servidores em-espera tendo pg_replication_slots.synced com o valor true). Os encaixes sincronizados são sempre considerados inativos, porque não realizam decodificação lógica para produzir alterações.

Fecha as conexões de replicação que estiverem inativas por mais tempo do que este período. Serve para o servidor de envio detectar uma falha no servidor em-espera ou interrupção da rede. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 60 segundos. O valor zero desativa o mecanismo de tempo esgotado (timeout).

Em um agrupamento distribuído por diversos locais geográficos, o uso de valores diferentes por local traz mais flexibilidade no gerenciamento do agrupamento. Um valor menor é útil para detecção mais rápida de falha em um servidor em-espera com uma conexão de rede de baixa latência, e um valor maior ajuda a avaliar melhor a integridade de um servidor em-espera localizado em um local remoto com uma conexão de rede de alta latência.

Registra a hora de efetivação das transações. Este parâmetro só pode ser definido na ativação do servidor. O padrão é off.

Especifica uma lista de servidores em-espera que podem dar suporte a replicação síncrona, conforme descrito em Replicação síncrona. Haverá um ou mais servidores em-espera síncronos ativos; as transações aguardando a efetivação poderão prosseguir após estes servidores em-espera confirmarem o recebimento de seus dados. Os servidores em-espera síncronos serão aqueles cujos nomes aparecem nesta lista, e conectados no momento e recebendo dados em tempo real (conforme mostrado pelo estado streaming na coluna state na visão pg_stat_replication). Especificar mais de um servidor em-espera síncrono pode permitir alta disponibilidade e proteção contra perda de dados.

O nome do servidor em-espera para este propósito é a configuração de application_name no servidor em-espera, conforme definido nas informações de conexão do servidor em-espera. No caso de um servidor em-espera de replicação física, deverá ser definido na configuração primary_conninfo; o padrão é a configuração de cluster_name, se definido, senão walreceiver. Para a replicação lógica, pode ser definido nas informações de conexão da subscrição, e o padrão é o nome da subscrição. Para outros consumidores de fluxo de replicação, veja sua documentação.

Este parâmetro especifica uma lista de servidores em-espera usando uma das seguintes sintaxes:

[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]

onde num_sync é o número de servidores em-espera síncronos dos quais as transações precisam aguardar respostas, e standby_name é o nome do servidor em-espera. num_sync deve ser um valor inteiro maior que zero. FIRST e ANY especificam o método para escolher esperas síncronas dos servidores listados.

A palavra-chave FIRST juntamente com num_sync, especifica uma replicação síncrona baseada em prioridade, e faz com que as efetivações de transação aguardem até que seus registros de WAL sejam replicados para num_sync servidores em-espera síncronos escolhidos com base em suas prioridades. Por exemplo, uma configuração FIRST 3 (s1, s2, s3, s4) fará com que cada efetivação espere por respostas de três servidores em-espera de maior prioridade escolhidos entre os servidores em-espera s1, s2, s3 e s4. Os servidores em-espera cujos nomes aparecem primeiro na lista recebem maior prioridade e serão considerados síncronos. Os outros servidores em-espera que apareçam depois nesta lista representam possíveis servidores em-espera síncronos. Se algum dos servidores em-espera síncrono corrente for desconectado por qualquer motivo, será substituído imediatamente pelo próximo servidores em-espera de prioridade mais alta. A palavra-chave FIRST é opcional.

A palavra-chave ANY juntamente com num_sync, especifica uma replicação síncrona baseada em quorum, fazendo com que as efetivações de transação aguardem até que seus registros de WAL sejam replicados para pelo menos num_sync servidores em-espera listados. Por exemplo, uma configuração ANY 3 (s1, s2, s3, s4) fará com que cada efetivação prossiga assim que pelo menos três servidores em-espera, entre s1, s2, s3 e s4, respondam.

FIRST e ANY não diferenciam letras maiúsculas de minúsculas. Se estas palavras-chave forem usadas como o nome de um servidor em-espera, seu standby_name deverá ser colocado entre aspas.

A terceira sintaxe era usada antes do PostgreSQL versão 9.6, e ainda recebe suporte. É o mesmo que a primeira sintaxe com FIRST e num_sync igual a 1. Por exemplo, FIRST 1 (s1, s2) e s1, s2 têm o mesmo significado: s1 ou s2 é escolhido como servidor em-espera síncrono.

A entrada especial * corresponde a qualquer nome de servidor em-espera.

Não há nenhum mecanismo para impor a unicidade dos nomes de servidores em-espera. No caso de duplicidade, um dos servidores em-espera correspondentes será considerado o de maior prioridade, embora exatamente qual seja indeterminado.

Se não for especificado nenhum nome de servidor em-espera síncrono aqui, a replicação síncrona não será ativada, e as efetivações de transação não aguardarão a replicação. Esta é a configuração padrão. Mesmo quando a replicação síncrona está ativa, as transações podem ser configuradas separadamente para não esperar pela replicação, definindo o parâmetro synchronous_commit como local ou off.

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

Lista (separada por vírgulas) de nomes de encaixes de servidores em-espera de replicação por fluxo (streaming), pelos quais os processos lógicos de envio de WAL irão aguardar. Os processos lógicos de envio de WAL enviarão alterações decodificadas aos plugins somente após os encaixes de replicação especificados confirmarem o recebimento do WAL. Isto garante que os encaixes de falha (failover) de replicação lógica não consumam alterações até que elas sejam recebidas e escritas nos servidores em-espera físicos correspondentes. Se uma conexão de replicação lógica precisar mudar para uma réplica em-espera física após a promoção dessa réplica, o encaixe de replicação física para a réplica em-espera deverá ser listado aqui. Note-se que a replicação lógica não prosseguirá se os encaixes especificados em synchronized_standby_slots não existirem ou forem invalidados. Além disso, as funções de gerenciamento de replicação pg_replication_slot_advance, pg_logical_slot_get_changes e pg_logical_slot_peek_changes, quando usadas com encaixes de falha lógicos, irão aguardar até que todos os encaixes físicos especificados em synchronized_standby_slots tenham confirmado o recebimento do WAL.

Os servidores em-espera correspondentes aos encaixes de replicação física em synchronized_standby_slots devem configurar sync_replication_slots = true para poderem receber alterações de encaixe de falha lógico do servidor primário.

Especifica a cadeia de caracteres de conexão a ser usada para que o servidor em-espera se conecte ao servidor de envio. Esta cadeia de caracteres está no formato descrito em Cadeias de caracteres de conexão. Se alguma opção não for especificada nesta cadeia de caracteres, será verificada a variável de ambiente correspondente (veja Variáveis ​​de ambiente). Se a variável de ambiente também não estiver definida, serão usados os valores padrão.

A cadeia de caracteres de conexão deve especificar o nome de hospedeiro (ou endereço) do servidor de envio, bem como o número da porta, se não for igual ao padrão do servidor em-espera. Também deve ser especificado um nome de usuário correspondente a uma função de banco de dados (identificador de autorização/role) com privilégios adequados no servidor de envio (veja Autenticação). Também será necessário fornecer a senha, se o servidor de envio exigir autenticação por senha. Pode ser fornecida na cadeia de caracteres primary_conninfo, ou em um arquivo ~/.pgpass em separado no servidor em-espera (deve ser usado replication como nome do hospedeiro no arquivo ~/.pgpass) (veja O arquivo de senhas).

Para a sincronização de encaixes de replicação (veja Replication Slot Synchronization), também é necessário especificar um dbname válido na cadeia de caracteres de primary_conninfo. Isto será usado apenas para a sincronização de encaixes, sendo ignorado para fluxo (streaming).

Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. Se este parâmetro for alterado enquanto o processo de recepção de WAL estiver em execução, este processo será sinalizado para terminar, esperando-se que reinicie com a nova configuração. (exceto se primary_conninfo for uma cadeia de caracteres vazia). Esta configuração não terá efeito se o servidor não estiver no modo em-espera.

Opcionalmente especifica um encaixe de replicação existente a ser usado ao conectar com o servidor de envio por meio de replicação por fluxo, para controlar a remoção de recursos no nó anterior (veja Encaixes de replicação). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. Se este parâmetro for alterado enquanto o processo de recepção de WAL estiver em execução, este processo será sinalizado para terminar, esperando-se que reinicie com a nova configuração. Esta configuração não terá efeito se primary_conninfo não estiver definido, ou se o servidor não estiver no modo em-espera.

Especifica se é possível ou não se conectar e executar consultas durante a restauração, conforme descrito em Servidor em-espera ativo. O padrão é on. Este parâmetro só pode ser definido na ativação do servidor. Só tem efeito durante a restauração de arquivamento, ou no modo em-espera.

Quando Hot Standby ^[126] está ativo, este parâmetro determina quanto tempo o servidor em-espera deve esperar antes de cancelar as instruções em-espera que estejam em conflito com entradas do WAL prestes a serem aplicadas, conforme descrito em Tratamento de conflitos de consulta. O parâmetro max_standby_archive_delay se aplica quando os dados de WAL estão sendo lidos do arquivamento de WAL (e, portanto, não é o corrente). Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 30 segundos. O valor -1 permite que o servidor em-espera aguarde indefinidamente a conclusão das instruções conflitantes. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Note-se que max_standby_archive_delay não é o mesmo que o tempo máximo que uma instrução pode ser executada antes do cancelamento; em vez disso, é o tempo total máximo permitido para aplicar os dados de qualquer segmento de WAL. Portanto, se uma instrução resultou em um atraso significativo no início do segmento de WAL, as instruções conflitantes subsequentes terão muito menos tempo de espera disponível.

Quando Hot Standby está ativo, este parâmetro determina quanto tempo o servidor em-espera deve esperar antes de cancelar as instruções em-espera que estejam em conflito com entradas de WAL prestes a serem aplicadas, conforme descrito em Tratamento de conflitos de consulta. O parâmetro max_standby_streaming_delay se aplica quando os dados de WAL estão sendo recebidos via replicação por fluxo. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 30 segundos. O valor -1 permite que o servidor em-espera aguarde indefinidamente a conclusão das instruções conflitantes. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Note-se que max_standby_streaming_delay não é o mesmo que o tempo máximo que uma instrução pode ser executada antes do cancelamento; em vez disso, é o tempo total máximo permitido para aplicar os dados de WAL uma vez recebidos do servidor primário. Portanto, se uma instrução resultou em um atraso significativo, as instruções conflitantes subsequentes terão muito menos tempo de espera disponível até que o servidor em-espera seja atualizado novamente.

Especifica se o processo de recepção de WAL deve criar um encaixe de replicação temporário na instância remota, quando não for configurado nenhum encaixe de replicação permanente para ser usado (usando primary_slot_name). O padrão é off. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. Se este parâmetro for alterado enquanto o processo de recepção de WAL estiver em execução, este processo será sinalizado para terminar, esperando-se que reinicie com a nova configuração.

Especifica a frequência mínima para o processo de recepção de WAL no servidor em-espera enviar informações sobre o progresso da replicação para o servidor primário ou anterior, o que pode ser visto usando a visão pg_stat_replication. O servidor em-espera irá relatar o último local de WAL que escreveu, a última posição que descarregou para o disco, e a última posição que aplicou. O valor desse parâmetro é o tempo máximo entre relatórios. As atualizações são enviadas sempre que as posições de escrita ou descarga mudam, ou no intervalo especificado por este parâmetro, se definido como um valor diferente de zero. Há casos adicionais em que as atualizações são enviadas ignorando este parâmetro; por exemplo, quando o processamento do WAL existente é concluído, ou quando synchronous_commit é definido como remote_apply. Portanto, a posição da aplicação pode ficar um pouco atrás da posição verdadeira. Se o valor for especificado sem unidade, será considerado sendo segundos. O padrão é 10 segundos. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica se um servidor em hot standby enviará ou não retorno para o servidor primário ou anterior sobre as instruções em execução no momento no servidor em-espera. Este parâmetro pode ser usado para eliminar cancelamentos de instrução causados por registros de limpeza, mas pode provocar sobrecarga no servidor primário para algumas cargas de trabalho. As mensagens de retorno não serão enviadas com mais frequência do que uma vez por wal_receiver_status_interval. O padrão é off. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Se estiver em uso a replicação em cascata, o retorno será passado para o servidor anterior até atingir o primário. Os servidores em-espera não fazem outro uso do retorno que recebem, a não ser passar para o anterior.

Note-se que, se o relógio do servidor em-espera estiver adiantado ou atrasado, a mensagem de confirmação poderá não ser enviada no intervalo exigido. Em casos extremos, isto poderá levar a um risco prolongado de não remoção de linhas inativas no servidor primário por períodos extensos, uma vez que o mecanismo de confirmação baseia-se em carimbos de data e hora.

Fecha as conexões de replicação inativas por mais tempo do que este período. Serve para o servidor em-espera de recebimento detectar uma falha no nó primário, ou interrupção da rede. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 60 segundos. O valor zero desativa o mecanismo de tempo esgotado (timeout). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica quanto tempo o servidor em-espera deve esperar quando os dados de WAL não estiverem disponíveis por nenhuma fonte (replicação por fluxo, pg_wal local, ou arquivamento de WAL) antes de tentar recuperar os dados de WAL novamente. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 5 segundos. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Este parâmetro é útil em configurações onde um nó em restauração precisa controlar o tempo de espera para que novos dados de WAL estejam disponíveis. Por exemplo, na restauração de arquivamento é possível tornar a restauração mais responsiva na detecção de um novo arquivo de WAL, reduzindo o valor desse parâmetro. Em um sistema com baixa atividade de WAL, aumentar reduz a quantidade de requisições necessárias para acessar os arquivos de WAL, algo útil, por exemplo, em ambientes de nuvem, onde se leva em consideração a quantidade de vezes que uma infraestrutura é acessada.

Na replicação lógica, este parâmetro também limita a frequência com que um processo trabalhador de aplicação de replicação ou um processo trabalhador de sincronização de tabela com falha será reiniciado.

Por padrão, um servidor em-espera restaura os registros de WAL do servidor de envio o mais rápido possível. Pode ser útil ter uma cópia dos dados com atraso, oferecendo oportunidades para corrigir erros de perda de dados. Este parâmetro permite atrasar a restauração por um tempo especificado. Por exemplo, se este parâmetro for definido como 5min, o servidor em-espera irá reproduzir cada efetivação de transação apenas quando a hora do sistema no servidor em-espera for de pelo menos cinco minutos após o momento de efetivação relatado pelo servidor primário. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é zero, ou seja, sem adição de atraso.

É possível que o atraso de replicação entre os servidores exceda o valor desse parâmetro, caso em que nenhum atraso será adicionado. Note-se que o atraso é calculado entre o carimbo de tempo do WAL, conforme escrito no servidor primário, e a hora corrente no servidor em-espera. Atrasos na transferência, devido ao atraso da rede ou configurações de replicação em cascata, podem reduzir muito o tempo de espera disponível. Se os relógios do sistema no servidor primário e no servidor em-espera não estiverem sincronizados, isto pode fazer com que a restauração aplique os registros antes do esperado; mas isto não é um problema importante, porque as configurações úteis desse parâmetro são muito maiores do que os desvios de tempo típicos entre servidores.

O atraso ocorre apenas em registros de WAL de efetivação de transação. Os demais registros são reexecutados o mais rapidamente possível, o que não é um problema, porque as regras de visibilidade do MVCC garantem que seus efeitos não sejam visíveis até que o registro de efetivação correspondente seja aplicado.

O atraso ocorre assim que o banco de dados em restauração atinge um estado consistente, até que o servidor em-espera seja promovido ou acionado. Após isto, o servidor em-espera encerrará a restauração sem mais esperar.

Os registros de WAL devem ser mantidos no servidor em-espera até que estejam prontos para serem aplicados. Portanto, atrasos mais longos resultarão em um maior acúmulo de arquivos de WAL, aumentando os requisitos de espaço em disco para o diretório pg_wal do servidor em-espera.

Este parâmetro destina-se ao uso em implantações de replicação por fluxo; entretanto, se o parâmetro for especificado, ele será respeitado em todos os casos, exceto na recuperação de falhas. hot_standby_feedback sofrerá atrasos com o uso desta funcionalidade, o que pode levar ao inchaço (bloat) no servidor primário; o uso dos dois em conjunto deve ser feito com cautela.

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

Permite que um servidor em-espera físico sincronize encaixes de falha lógicos a partir do servidor primário, de modo que os subscritores lógicos possam retomar a replicação a partir do novo servidor primário após a falha.

Está inativo por padrão. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Especifica quantas origens de replicação (veja Acompanhamento do progresso da replicação) podem ser monitoradas ao mesmo tempo, limitando efetivamente quantas subscrições de replicação lógica podem ser criadas no servidor. Definir este valor para um número inferior ao número corrente de origens de replicação monitoradas (mostrado em pg_replication_origin_status) impedirá a ativação do servidor. O padrão é 10. Este parâmetro só pode ser definido na ativação do servidor. max_active_replication_origins deve ser definido, no mínimo, como o número de subscrições a serem adicionadas ao subscritor, mais uma margem de reserva para a sincronização de tabela.

Especifica o número máximo de processos trabalhadores de replicação lógica. Isto inclui processos trabalhadores de aplicação líderes, processos trabalhadores de aplicação paralelos e processos trabalhadores de sincronização de tabelas.

Os processos trabalhadores de replicação lógica são obtidos do conjunto definido por max_worker_processes.

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

Número máximo de processos trabalhadores de sincronização por subscrição. Este parâmetro controla a quantidade de paralelismo da cópia inicial dos dados durante a inicialização da subscrição, ou quando são incluídas novas tabelas.

No momento, só pode haver um processo trabalhador de sincronização por tabela.

Os processos trabalhadores de sincronização são retirados do pool definido por max_logical_replication_workers.

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

Número máximo de processos trabalhadores paralelos de aplicação por subscrição. Este parâmetro controla o nível de paralelismo para o fluxo de transações em andamento com o parâmetro de subscrição. streaming = parallel.

Os processos trabalhadores de aplicação em paralelo são obtidos do conjunto definido por max_logical_replication_workers.

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